What's the "right" way to do modules under iOS

[Guglielmo Braguglia]

Hi Ken,
if I understand well, your idea is to have a main module that download 
other executable modules (/livecode stacks/) ...
... if this is correct ... look into "App Store Review Guidelines" :

2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected

... so ... be careful !!!

Guglielmo


On 24.02.2012 13:13, Ken Corey wrote:
> Hi All,
>
> I'm building a large set of applications in LiveCode that work together.
>
> There's the initial login module, and once logged in you're given 
> access to the modules that user is elligible for.
>
> The login module is working more or less the way I want, but the other 
> modules are currently in development.  Once I get the first one 
> working, I'll be developing the second.
>
> I've noticed that trying the code on the iPad is taking longer and 
> longer between <code> <transefer> and <test> steps.  It's taking long 
> enough for me to want a different approach. Ideally only downloading 
> the code that changes, so I don't have to shuffle the assets back and 
> forth time and again.
>
> There are two separate problems:
> 1) How does this translate into LiveCode semantics?
> 2) How does this translate into LiveCode semantics under iOS?
>
> For #1, I'm envisioning being able to download each module as a 
> separate standalone, and open it as a substack from within the Login 
> module. Is that the way it should work, or is there a better way?
>
> For #2, doesn't this technically count as "downloading executable 
> code" under iOS, which would make it a no-no?  What's the principle of 
> IAP when it's adding new functionality?  I read the IAP tutorial on 
> runrev's site, and it wasn't discussed.
>
> I can imagine a few ways to deal with it:
>
> 1) cross fingers, hope for the best, and design the app so that when 
> new functionality is purchased it's downloaded.  (Not great, because 
> the risk is high from Apple's capricious app management team).
> 2) Always have all the smarts in the main standalone, and have it 
> dynamically download the assets for any purchased modules.  When a new 
> module is released, the whole standalone is updated with the code for 
> all modules, just without assets.  Then when the user has paid for a 
> given module they can download the assets for that module.  (Not 
> great, as the <code><transfer><test> cycle gets longer the more I code.
> 3) Give up completely, and have each module in a separate app.  If the 
> user wants to switch between apps, the user must login afresh each 
> time (PITA for the user), or I need to have long-lived cookies for 
> login (security nightmare).
>
> Also, does this mean that all assets are stored on my servers or can 
> the assets for the IAP modules be stored on Apple's servers?
>
> What's the right way if I'm going to be releasing on iOS?  Is there a 
> tutorial for adding substacks via IAP yet?
>
> Thanks,
>
> -Ken
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>