New iOS App rejections & warnings - executable size and PIE

[markw]

Canary in the coal mine moment on the use list this week. An app was rejected for having an executable that's too big and also got a warning about not having position independent code.

In this case the app was doing some horribly inefficient stuff with images but it's worth considering the more general consequences.

The executable size limit appears to have been introduced (or at least review failures started getting reported online) in March - it was 60MB then, looks like they might have raised it to 80MB. If LiveCode is not going to start forcing everyone to write things to include all media external to the stack then would it be feasible to consider the build process separating them out automatically, or not including the main stack in the executable at all and simply have the engine load it?

Is there a reason why LiveCode generated executables aren't position independent, or does a flag just need setting for the build?

I suspect these new automated checks on app binaries are either a subtle crack down on low quality apps built with 3rd party tools or they forewarn requirements for some new products or tools. I'd be surprised if the PIE warning didn't become a mandatory failure at some time in the not too distant future.

[LCMark]

Canary in the coal mine moment on the use list this week. An app was rejected for having an executable that's too big and also got a warning about not having position independent code.

I noticed that thread too...

The executable size limit appears to have been introduced (or at least review failures started getting reported online) in March - it was 60MB then, looks like they might have raised it to 80MB. If LiveCode is not going to start forcing everyone to write things to include all media external to the stack then would it be feasible to consider the build process separating them out automatically, or not including the main stack in the executable at all and simply have the engine load it?

In the short-term this just requires a small tweak to the standalone builder - there's already an option on the internal 'deploy' command to 'spill' the LiveCode content out of the main executable and into an auxiliary file. I must confess I thought we'd already made that change (as it reduces the size of multi-architecture binaries) - but clearly not...

In the longer-term it would be nice if during standalone building 'embedded' images (in particular) were removed and placed in separate files. With a few small tweaks to the image object it should be possible to make this entirely transparent to script. This would also work well with the new image caching feature since 6.0 - which works best when image's are referenced by file.

Is there a reason why LiveCode generated executables aren't position independent, or does a flag just need setting for the build?

I think it's just a case of enabling the PIE flag - it's on the list for 6.1.

I suspect these new automated checks on app binaries are either a subtle crack down on low quality apps built with 3rd party tools or they forewarn requirements for some new products or tools. I'd be surprised if the PIE warning didn't become a mandatory failure at some time in the not too distant future.

I suspect the PIE thing will become mandatory soon too - from what I've read if an app isn't compiled with PIE then it can't use Address Space Layout Randomization which I think iOS started doing in 6.0.

[markw]

Great stuff - good to hear this is all in hand.

I guess the PIE stuff is all part of them adding security features to get more traction in the enterprise market.

Curious whether the executable size limit is related (i.e. if you're repositioning the executable it's size determines the limits of where you can do that) or because they've got something else in the works (either a new product with less capable hardware, or maybe a more comprehensive binary scanning tool which for cost reasons they want to limit the memory usage of).

I guess it would make sense to wait for the restructure of the engine and build system to be complete before anyone looks at automatically splitting out images to separate files?

Mark

[Colin Holgate]

Something came up in the Flash forums, where they too have updated AIR so that it's compliant with PIE. People were still having problems with AIR extensions, even with the PIE compliant version of AIR they were getting the error message when submitting apps.

Turns out that PIE requires a minimum iOS SDK of 4.2. So, if anything in LiveCode is built for a minimum of iOS 4.0 for example, then the PIE warning would most likely happen. People making those AIR extensions just have to rebuild the extension with <option>-ios_version_min 4.2</option>, and that solves the problem.

[monte]

Hmm... @runrevmark you might want to add some notes to the iOS Externals SDK if there's any requirements.