Hi!
Since Apple forbids an iOS app from dynamically loading code, how will blueprints fare? Do they get compiled through C++, or are they “data” that gets executed by code already in the app?
A scenario: I want to add an asset to a DLC pack, and this asset configures a material through a blueprint. Will I be able to ship that without updating the app?
Since I’m not getting an answer, I’m assuming Blueprints will be considered Script by Apple, and will require a review cycle by Apple staff if modified or added through DLC.
Sorry we didn’t answer this sooner. If the blueprints utilize code already in the shipped executable (i.e. no new blueprint nodes are added), then it should just be considered an asset. However, this is definitely in the grey area as you are changing functionality even though you didn’t update the code. I solicit some opinions from around here and see what the consensus is.
-Pete
Any updates on this?
With the release of iOS 9 and tvOS utilizing On-Demand Resources prohibits the inclusion of code. If the DLC .pak files contain any dylibs from blueprints I would imagine it would not be allowed.
Blueprints are just bytecode, so you can definitely include them in a .pak file and distribute that as DLC / On-Demand Resources without apple giving you any trouble. The docs state the the C++ emitter is for debugging purposes only, and after some testing no new dylib was emitted into any DLC pak files I tested with.
Initially I was also confused about what a Blueprint was, but found the docs and it looks like it is all just built on the old Kismet VM.
I agree, its just bytecode, but bytecode is also what gets emitted by most compiled script languages, and even some languages not really considered as script, like the .NET family and Java.
The Apple guideline is there to catch important changes in App behavior so it gets reviewed properly. In my mind, script could do that, maybe activating functionality that was never activated in an earlier released but still shipped, and thus not reviewed. I agrees with psauer above that this is a grey area 
C# and Java are normally JIT languages so they are AOT compiled on iOS typically, and that produces new code when you make changes thus requiring new libraries be linked in or your binary executable to be recompiled.
Blueprint, and for example, Lua do no such thing. To further ease your mind, check out the documentation for On-Demand Resources specifically…
A data file can contain any sort of
data except for executable Swift,
Objective-C, C, or C++ code. Files
generated by scripting languages can
be on-demand resources.
If your worry is that you are going to trigger another app review when you add your DLC, that in and of itself, may be unavoidable. The minute you add an in-app purchase to sell your DLC your app will trigger a review. In my experience the review for the in-app purchase after an existing app is on the store is not as long as the original review.
Out of curiosity, never shipped DLC on iOS… How do they detect you added a new pack? Not all apps require the app to be updated when they add DLC, their app might very well be looking at an independent source of data. Or is that disallowed? Anyway, I guess DLC is fair game for a review cycle, so you should prepare for it.
Out of the context of an In-App Purchase I’m not sure. Every time we added extensions to a product we update the In-App Purchase list and that requires review against our new app.
I also have another app on the store that downloads content from an online source in order to run, and it only needed one review cycle, even if the content source changes. No scripting comes down the pipe in that app though, just XML files and Images.