Re: First App rejected for odd reasons

2013-06-05 Thread Mark Wilcox
 I may be wrong about this (can anyone verify?), but if you're building for 
 iOS 5 or later, you should be perfectly safe selecting armv7 only and 
 building for that, since any devices capable of running iOS 5 and above are 
 armv7 devices only.


Yes, this is correct and a good idea - the iPhone 3G was the last device to 
have an ARMv6 processor and that can only run iOS 4.3 or earlier - that's why 
Apple has dropped support for armv6 builds from the more recent Xcode versions.

I expect (really hope) that LiveCode only duplicates the engine code within the 
Universal binary and puts the main stack in a data section that is shared by 
both code variants - if that's the case, this might only save you a few 
megabytes of engine code, but you should do it anyway - iOS5+ with armv6 is 
pure waste.

I'd not seen the main executable size issue before and a quick Google suggests 
both this and the not yet mandatory PIE warning are new.  This is either a 
subtle crackdown on low quality apps produced by tools other than XCode or 
there are some new products or tools on the way which will care about this in 
the future.  I'll bring it up on the engine forum.

As I understand it, only the main stack is actually bundled inside the 
executable in a standalone, so a simple fix would be to create a launcher stack 
as your main stack which simply loads the previous main stack which you can 
include in the bundle separately.  However, creating apps much, much larger 
than they need to be is not friendly to your users.  Large images should be 
JPEG compressed - if they contain text that loses quality due to JPEG 
compression then split the images up (or if it's all text, store it as text not 
an image!).  Audio should also be in a suitable compressed format (i.e. not 
WAV).

In this case it sounds like LiveCode 6's application browser might be handy for 
finding out what's actually inside the stack easily, then removing all the 
media and referencing it externally.  Otherwise it might be easier to rebuild 
the stack by copying the scripts across into a new one that only references 
external media from the start?

Mark



 From: Chris Sheffield cmsheffi...@icloud.com
To: How to use LiveCode use-livecode@lists.runrev.com 
Sent: Monday, 3 June 2013, 20:54
Subject: Re: First App rejected for odd reasons
 

Another thought. In the standalone settings, are you building a universal 
binary? I may be wrong about this (can anyone verify?), but if you're building 
for iOS 5 or later, you should be perfectly safe selecting armv7 only and 
building for that, since any devices capable of running iOS 5 and above are 
armv7 devices only. This may also reduce the size of your executable.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-05 Thread Thomas McGrath III
Mark,

At first I wanted to object to the need for JPEG only for large images as all 
of the research that I have done (especially concerning transparency issues) 
has told me to never use JPEG (except for the web) in most of my apps but then 
I realized that I have not tested those same results for iOS and Android 
engines, so I will need to do those tests again to verify/reject my findings. 
That said, using 2048 png's with transparency layers on fourteen cards with 
special visual effects and playing song files on one channel and a voice over 
on another channel did not slow down either the logic code or the effects code. 
I created a Ken Burns effect in LC and it runs as smoothly with the larger 
images as it does with smaller variations. So I'm not sure what would 
constitute a stack being 'much larger' than it needs to be - in my first case 
it was the main stack that was large and now it is the images folder that is 
large - either way the download is going to be the same size and be too big for 
cellular download (which is why I believe Apple has that warning in the first 
place.) I would not think that 14 retina sized images on 14 different cards is 
too large for a mobile app and that instead they must be referenced and that 
that would be a requirement. Normally I think if it was like 50 images it 
should be referenced but not just 14. Most LC projects I have seen all use 
lower quality images or regular 1024 images enlarged for retina via code, but 
they are definitely not retina images.

All of that said, I think what you stated is spot on and should be included in 
a best practices type document somewhere for mobile development. Maybe with 
some recommendations for audio and compression comparisons.

Thanks,

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 5, 2013, at 5:21 AM, Mark Wilcox m_p_wil...@yahoo.co.uk wrote:

 I may be wrong about this (can anyone verify?), but if you're building for 
 iOS 5 or later, you should be perfectly safe selecting armv7 only and 
 building for that, since any devices capable of running iOS 5 and above are 
 armv7 devices only.
 
 
 Yes, this is correct and a good idea - the iPhone 3G was the last device to 
 have an ARMv6 processor and that can only run iOS 4.3 or earlier - that's why 
 Apple has dropped support for armv6 builds from the more recent Xcode 
 versions.
 
 I expect (really hope) that LiveCode only duplicates the engine code within 
 the Universal binary and puts the main stack in a data section that is shared 
 by both code variants - if that's the case, this might only save you a few 
 megabytes of engine code, but you should do it anyway - iOS5+ with armv6 is 
 pure waste.
 
 I'd not seen the main executable size issue before and a quick Google 
 suggests both this and the not yet mandatory PIE warning are new.  This is 
 either a subtle crackdown on low quality apps produced by tools other than 
 XCode or there are some new products or tools on the way which will care 
 about this in the future.  I'll bring it up on the engine forum.
 
 As I understand it, only the main stack is actually bundled inside the 
 executable in a standalone, so a simple fix would be to create a launcher 
 stack as your main stack which simply loads the previous main stack which you 
 can include in the bundle separately.  However, creating apps much, much 
 larger than they need to be is not friendly to your users.  Large images 
 should be JPEG compressed - if they contain text that loses quality due to 
 JPEG compression then split the images up (or if it's all text, store it as 
 text not an image!).  Audio should also be in a suitable compressed format 
 (i.e. not WAV).
 
 In this case it sounds like LiveCode 6's application browser might be handy 
 for finding out what's actually inside the stack easily, then removing all 
 the media and referencing it externally.  Otherwise it might be easier to 
 rebuild the stack by copying the scripts across into a new one that only 
 references external media from the start?
 
 Mark
 
 
 
 From: Chris Sheffield cmsheffi...@icloud.com
 To: How to use LiveCode use-livecode@lists.runrev.com 
 Sent: Monday, 3 June 2013, 20:54
 Subject: Re: First App rejected for odd reasons
 
 
 Another thought. In the standalone settings, are you building a universal 
 binary? I may be wrong about this (can anyone verify?), but if you're 
 building for iOS 5 or later, you should be perfectly safe selecting armv7 
 only and building for that, since any devices capable of running iOS 5 and 
 above are armv7 devices only. This may also reduce the size of your 
 executable.
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use

Re: First App rejected for odd reasons

2013-06-05 Thread Thomas McGrath III
I hope that didn't sound argumentative. I think this topic needs more 
discussion and input.

Thanks again Mark for the input on this.

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 5, 2013, at 8:41 AM, Thomas McGrath III mcgra...@mac.com wrote:

 Mark,
 
 At first I wanted to object to the need for JPEG only for large images as all 
 of the research that I have done (especially concerning transparency issues) 
 has told me to never use JPEG (except for the web) in most of my apps but 
 then I realized that I have not tested those same results for iOS and Android 
 engines, so I will need to do those tests again to verify/reject my findings. 
 That said, using 2048 png's with transparency layers on fourteen cards with 
 special visual effects and playing song files on one channel and a voice over 
 on another channel did not slow down either the logic code or the effects 
 code. I created a Ken Burns effect in LC and it runs as smoothly with the 
 larger images as it does with smaller variations. So I'm not sure what would 
 constitute a stack being 'much larger' than it needs to be - in my first case 
 it was the main stack that was large and now it is the images folder that is 
 large - either way the download is going to be the same size and be too big 
 for
 cellular download (which is why I believe Apple has that warning in the first 
 place.) I would not think that 14 retina sized images on 14 different cards 
 is too large for a mobile app and that instead they must be referenced and 
 that that would be a requirement. Normally I think if it was like 50 images 
 it should be referenced but not just 14. Most LC projects I have seen all use 
 lower quality images or regular 1024 images enlarged for retina via code, but 
 they are definitely not retina images.
 
 All of that said, I think what you stated is spot on and should be included 
 in a best practices type document somewhere for mobile development. Maybe 
 with some recommendations for audio and compression comparisons.
 
 Thanks,
 
 Tom


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-05 Thread Mark Wilcox
Hi Tom,

No need to test JPEGs again on iOS/Android - the JPEG format itself doesn't 
support transparency! :)

If you need transparency then there is another option which is to store the 
image and it's mask (effectively alpha channel) separately, although I've not 
worked with these features in LiveCode.

If you have a number of very large images such that your app is genuinely 
hundreds of megabytes it's worth doing some optimisation - some users will not 
download really big apps to avoid using up limited storage space on their 
device.  From a performance perspective any further compression of the data 
(e.g. JPEGs are smaller) actually makes more work for the device decompressing 
it although you're unlikely to notice the difference - it's only when you're 
downloading the images that making them smaller improves performance.

One uncompressed image at iPad retina resolution is at least 12MB. 14 of those 
is 168MB.  I generalised on large images before - PNGs can be very good for 
compressing images with relatively few colours in large blocks but terrible for 
compressing photographs.  That said, sticking with PNG there are ways to get 
the exact same image much smaller with a better compressor.  Take a look at 
this:
http://imageoptim.com/ipad.html


On the engine forum Mark Waddingham has said that they can tweak the build 
process to remove images (and even the main stack) from the executable fairly 
easily for future releases.  Then the executable will only be about the size of 
the compiled engine, even if the app itself is much bigger.

Mark's response also hinted that maybe if you're building a universal binary 
(i.e. more than just armv7) you might be getting 2 copies of everything in the 
main stack within the executable.

 So I'm not sure what would constitute a stack being 'much larger' than it 
 needs to be - in my first case it was the main stack that was large and now 
 it is the images folder that is large - either way the download is going to 
 be the same size and be too big for cellular download (which is why I 
 believe Apple has that warning in the first place.)


Well, for a photograph, a PNG might give you 4:1 compression while due to the 
retina nature of the iPad display you typically can't see the reduced quality 
for the same image at medium quality 40:1 JPEG compression - full resolution 
with more compression usually looks better than 25% (original iPad) resolution 
with less compression.  I'd say 10x the size is much bigger. :)

The size restriction is new and unrelated to the 3G download limit (which is 
50MB). For now we can only speculate what the limit is for.

Mark



 From: Thomas McGrath III mcgra...@mac.com
To: How to use LiveCode use-livecode@lists.runrev.com 
Sent: Wednesday, 5 June 2013, 13:41
Subject: Re: First App rejected for odd reasons
 

Mark,

At first I wanted to object to the need for JPEG only for large images as all 
of the research that I have done (especially concerning transparency issues) 
has told me to never use JPEG (except for the web) in most of my apps but then 
I realized that I have not tested those same results for iOS and Android 
engines, so I will need to do those tests again to verify/reject my findings. 
That said, using 2048 png's with transparency layers on fourteen cards with 
special visual effects and playing song files on one channel and a voice over 
on another channel did not slow down either the logic code or the effects code. 
I created a Ken Burns effect in LC and it runs as smoothly with the larger 
images as it does with smaller variations. So I'm not sure what would 
constitute a stack being 'much larger' than it needs to be - in my first case 
it was the main stack that was large and now it is the images folder that is 
large - either way the download is going to be
 the same size and be too big for cellular download (which is why I believe 
Apple has that warning in the first place.) I would not think that 14 retina 
sized images on 14 different cards is too large for a mobile app and that 
instead they must be referenced and that that would be a requirement. Normally 
I think if it was like 50 images it should be referenced but not just 14. Most 
LC projects I have seen all use lower quality images or regular 1024 images 
enlarged for retina via code, but they are definitely not retina images.

All of that said, I think what you stated is spot on and should be included in 
a best practices type document somewhere for mobile development. Maybe with 
some recommendations for audio and compression comparisons.

Thanks,

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Colin Holgate
You need to use 5.5.5 to get past the UDID problem, and the other errors are 
not ones that will stop it from being approved.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Tom,

To get rid of the UDID issue, you'll need to install and use the latest LC 
5.5.5 update. It fixes that problem.

The push notification entitlement issue is a non-issue. Your app can get 
approved even with that warning.

As for the executable size, I wasn't really aware of any limits, so I find that 
kind of odd. Are your images embedded in your app (imported as controls into 
your stack)? If so, is it possible to reference any of them on disk instead 
using the filename property? So they could still be part of your app bundle, 
but not be embedded in the executable. Not sure if that's the issue or not. 
Kind of guessing here. But it seems like the error is referring to the actual 
executable, not necessarily the app bundle.

As for the Non-PIE binary, I'm not sure about that one either, but I'm curious 
to find out what it means.

Chris


--
Chris Sheffield
Read Naturally, Inc.
www.readnaturally.com



On Jun 3, 2013, at 11:25 AM, Thomas McGrath III mcgra...@mac.com wrote:

 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Binary was rejected as invalid. I am not using Push 
 notification. I am not accessing the UDID. The project is large because it 
 has 2048x1536 images in it for Retina iPad it is 387 MB. I don't know what a 
 Non-PIE Binary is but I am looking it up now.
 
 This was built with Livecode 5.5.4 Any Ideas?
 
 Non-public API usage:
 
 Apps are not permitted to access the UDID and must not use the 
 uniqueIdentifier method of UIDevice. Please update your apps and servers to 
 associate users with the Vendor or Advertising identifiers introduced in iOS 
 6.
 
 Invalid Executable Size - Your app's executable file 
 'GospelOfMark.app/GospelOfMark' is a size of 249868688 bytes, which exceeds 
 the maximum allowed size of 80 MB. Abnormally large executable files are 
 often the result of using a development environment that stores excessive or 
 unnecessary data in the compiled binary. You may need to contact your tool 
 vendor for assistance if your app was built with a developer tool other than 
 Xcode.
 
 Missing Push Notification Entitlement - Your app appears to include API used 
 to register with the Apple Push Notification service, but the app signature's 
 entitlements do not include the aps-environment entitlement.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
 Independent Executable. Please ensure that your build settings are configured 
 to create PIE executables. For more information, refer to Technical QA 
 QA1788 - Building a Position Independent Executable
 
 ---
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Colin, Thanks for getting back to me. My app crashes on a device with 5.5.5 so 
I went back to 5.5.4

Also, the Non-PIE goes away by building for iOS 4.3 or later. I had the default 
3.1.3 or Later selected so I changed that.

I will see what the rejection is for this new upload and then try the 5.5.5 
again.

Tom


-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 1:35 PM, Colin Holgate co...@verizon.net wrote:

 You need to use 5.5.5 to get past the UDID problem, and the other errors are 
 not ones that will stop it from being approved.
 
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Chris,

I just replied to Colin about the Non-PIE issue but the gist was to build for 
iOS 4.3 or later.

If I update to get rid of the UDID issue I will see if I still get the other 
errors and if so then I will try and build with references instead of embedded 
images.

Thanks

Tom 

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 1:37 PM, Chris Sheffield cmsheffi...@icloud.com wrote:

 Tom,
 
 To get rid of the UDID issue, you'll need to install and use the latest LC 
 5.5.5 update. It fixes that problem.
 
 The push notification entitlement issue is a non-issue. Your app can get 
 approved even with that warning.
 
 As for the executable size, I wasn't really aware of any limits, so I find 
 that kind of odd. Are your images embedded in your app (imported as controls 
 into your stack)? If so, is it possible to reference any of them on disk 
 instead using the filename property? So they could still be part of your app 
 bundle, but not be embedded in the executable. Not sure if that's the issue 
 or not. Kind of guessing here. But it seems like the error is referring to 
 the actual executable, not necessarily the app bundle.
 
 As for the Non-PIE binary, I'm not sure about that one either, but I'm 
 curious to find out what it means.
 
 Chris
 
 
 --
 Chris Sheffield
 Read Naturally, Inc.
 www.readnaturally.com
 
 
 
 On Jun 3, 2013, at 11:25 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Binary was rejected as invalid. I am not using Push 
 notification. I am not accessing the UDID. The project is large because it 
 has 2048x1536 images in it for Retina iPad it is 387 MB. I don't know what a 
 Non-PIE Binary is but I am looking it up now.
 
 This was built with Livecode 5.5.4 Any Ideas?
 
 Non-public API usage:
 
 Apps are not permitted to access the UDID and must not use the 
 uniqueIdentifier method of UIDevice. Please update your apps and servers to 
 associate users with the Vendor or Advertising identifiers introduced in iOS 
 6.
 
 Invalid Executable Size - Your app's executable file 
 'GospelOfMark.app/GospelOfMark' is a size of 249868688 bytes, which exceeds 
 the maximum allowed size of 80 MB. Abnormally large executable files are 
 often the result of using a development environment that stores excessive or 
 unnecessary data in the compiled binary. You may need to contact your tool 
 vendor for assistance if your app was built with a developer tool other than 
 Xcode.
 
 Missing Push Notification Entitlement - Your app appears to include API used 
 to register with the Apple Push Notification service, but the app 
 signature's entitlements do not include the aps-environment entitlement.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
 Independent Executable. Please ensure that your build settings are 
 configured to create PIE executables. For more information, refer to 
 Technical QA QA1788 - Building a Position Independent Executable
 
 ---
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Mark Schonewille

Hi Tom,

Have you removed the old app completely from your device? This may be 
necessary before you can get your app running with LC 5.5.5.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Use Color Converter to convert CMYK, RGB, RAL, XYZ, H.Lab and other 
colour spaces. http://www.color-converter.com


Buy my new book Programming LiveCode for the Real Beginner 
http://qery.us/3fi


On 6/3/2013 19:38, Thomas McGrath III wrote:

Colin, Thanks for getting back to me. My app crashes on a device with 5.5.5 so 
I went back to 5.5.4

Also, the Non-PIE goes away by building for iOS 4.3 or later. I had the default 
3.1.3 or Later selected so I changed that.

I will see what the rejection is for this new upload and then try the 5.5.5 
again.

Tom




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Paul Maguire
Hi.

You need to update to 5.5.5 to avoid 2 of these errors: UDID, and non-PIE. Get 
it from the Livecode site.

On 3 Jun 2013, at 18:25, Thomas McGrath III wrote:
 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Any Ideas?



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Chris,

I just reduced all of my embedded images to 1024 instead of 2048 which should 
have changed the size of the app somewhat. But I am getting only a 6 meg 
reduction from 387 down to 381 Is there a way to recover the space used by 
those images? I tried to compact this stack but no change (besides I thought 
save did that from the file menu)


-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 1:37 PM, Chris Sheffield cmsheffi...@icloud.com wrote:

 Tom,
 
 To get rid of the UDID issue, you'll need to install and use the latest LC 
 5.5.5 update. It fixes that problem.
 
 The push notification entitlement issue is a non-issue. Your app can get 
 approved even with that warning.
 
 As for the executable size, I wasn't really aware of any limits, so I find 
 that kind of odd. Are your images embedded in your app (imported as controls 
 into your stack)? If so, is it possible to reference any of them on disk 
 instead using the filename property? So they could still be part of your app 
 bundle, but not be embedded in the executable. Not sure if that's the issue 
 or not. Kind of guessing here. But it seems like the error is referring to 
 the actual executable, not necessarily the app bundle.
 
 As for the Non-PIE binary, I'm not sure about that one either, but I'm 
 curious to find out what it means.
 
 Chris
 
 
 --
 Chris Sheffield
 Read Naturally, Inc.
 www.readnaturally.com
 
 
 
 On Jun 3, 2013, at 11:25 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Binary was rejected as invalid. I am not using Push 
 notification. I am not accessing the UDID. The project is large because it 
 has 2048x1536 images in it for Retina iPad it is 387 MB. I don't know what a 
 Non-PIE Binary is but I am looking it up now.
 
 This was built with Livecode 5.5.4 Any Ideas?
 
 Non-public API usage:
 
 Apps are not permitted to access the UDID and must not use the 
 uniqueIdentifier method of UIDevice. Please update your apps and servers to 
 associate users with the Vendor or Advertising identifiers introduced in iOS 
 6.
 
 Invalid Executable Size - Your app's executable file 
 'GospelOfMark.app/GospelOfMark' is a size of 249868688 bytes, which exceeds 
 the maximum allowed size of 80 MB. Abnormally large executable files are 
 often the result of using a development environment that stores excessive or 
 unnecessary data in the compiled binary. You may need to contact your tool 
 vendor for assistance if your app was built with a developer tool other than 
 Xcode.
 
 Missing Push Notification Entitlement - Your app appears to include API used 
 to register with the Apple Push Notification service, but the app 
 signature's entitlements do not include the aps-environment entitlement.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
 Independent Executable. Please ensure that your build settings are 
 configured to create PIE executables. For more information, refer to 
 Technical QA QA1788 - Building a Position Independent Executable
 
 ---
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Paul,

I am now trying to build with 5.5.5 and I still got all four errors. Checking 
again now.

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 1:37 PM, Paul Maguire m...@paulmaguire.me wrote:

 Hi.
 
 You need to update to 5.5.5 to avoid 2 of these errors: UDID, and non-PIE. 
 Get it from the Livecode site.
 
 On 3 Jun 2013, at 18:25, Thomas McGrath III wrote:
 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Any Ideas?
 
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am still 
getting a Binary rejection for Three of the four reasons:

Invalid Executable Size - Your app's executable file 
'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds the 
maximum allowed size of 80 MB. Abnormally large executable files are often the 
result of using a development environment that stores excessive or unnecessary 
data in the compiled binary. You may need to contact your tool vendor for 
assistance if your app was built with a developer tool other than Xcode. If 
your app was built using Xcode, you may contactApple Developer Technical 
Support if you need assistance.

Though you are not required to fix the following issues, we wanted to make you 
aware of them:

Missing Push Notification Entitlement - Your app appears to include API used to 
register with the Apple Push Notification service, but the app signature's 
entitlements do not include the aps-environment entitlement. If your app uses 
the Apple Push Notification service, make sure your App ID is enabled for Push 
Notification in the Provisioning Portal, and resubmit after signing your app 
with a Distribution provisioning profile that includes the aps-environment 
entitlement. See Provisioning and Development in the Local and Push 
Notification Programming Guide for more information. If your app does not use 
the Apple Push Notification service, no action is required. You may remove the 
API from future submissions to stop this warning. If you use a third-party 
framework, you may need to contact the developer for information on removing 
the API.

Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
Independent Executable. Please ensure that your build settings are configured 
to create PIE executables. For more information, refer to Technical QA QA1788 
- Building a Position Independent Executable



Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Interesting. What else do you have in there that's making the executable so 
large? Embedded sounds possibly? If so, again, I would recommend removing them 
from your stack and referencing them by filename instead.


On Jun 3, 2013, at 12:14 PM, Thomas McGrath III mcgra...@mac.com wrote:

 Chris,
 
 I just reduced all of my embedded images to 1024 instead of 2048 which should 
 have changed the size of the app somewhat. But I am getting only a 6 meg 
 reduction from 387 down to 381 Is there a way to recover the space used by 
 those images? I tried to compact this stack but no change (besides I thought 
 save did that from the file menu)
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 1:37 PM, Chris Sheffield cmsheffi...@icloud.com wrote:
 
 Tom,
 
 To get rid of the UDID issue, you'll need to install and use the latest LC 
 5.5.5 update. It fixes that problem.
 
 The push notification entitlement issue is a non-issue. Your app can get 
 approved even with that warning.
 
 As for the executable size, I wasn't really aware of any limits, so I find 
 that kind of odd. Are your images embedded in your app (imported as controls 
 into your stack)? If so, is it possible to reference any of them on disk 
 instead using the filename property? So they could still be part of your app 
 bundle, but not be embedded in the executable. Not sure if that's the issue 
 or not. Kind of guessing here. But it seems like the error is referring to 
 the actual executable, not necessarily the app bundle.
 
 As for the Non-PIE binary, I'm not sure about that one either, but I'm 
 curious to find out what it means.
 
 Chris
 
 
 --
 Chris Sheffield
 Read Naturally, Inc.
 www.readnaturally.com
 
 
 
 On Jun 3, 2013, at 11:25 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 I just tried to upload a free app to the Apple App Store and was 
 immediately rejected. I have seen some people get some of these warning but 
 I got four reasons and the Binary was rejected as invalid. I am not using 
 Push notification. I am not accessing the UDID. The project is large 
 because it has 2048x1536 images in it for Retina iPad it is 387 MB. I don't 
 know what a Non-PIE Binary is but I am looking it up now.
 
 This was built with Livecode 5.5.4 Any Ideas?
 
 Non-public API usage:
 
 Apps are not permitted to access the UDID and must not use the 
 uniqueIdentifier method of UIDevice. Please update your apps and servers to 
 associate users with the Vendor or Advertising identifiers introduced in 
 iOS 6.
 
 Invalid Executable Size - Your app's executable file 
 'GospelOfMark.app/GospelOfMark' is a size of 249868688 bytes, which exceeds 
 the maximum allowed size of 80 MB. Abnormally large executable files are 
 often the result of using a development environment that stores excessive 
 or unnecessary data in the compiled binary. You may need to contact your 
 tool vendor for assistance if your app was built with a developer tool 
 other than Xcode.
 
 Missing Push Notification Entitlement - Your app appears to include API 
 used to register with the Apple Push Notification service, but the app 
 signature's entitlements do not include the aps-environment entitlement.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
 Independent Executable. Please ensure that your build settings are 
 configured to create PIE executables. For more information, refer to 
 Technical QA QA1788 - Building a Position Independent Executable
 
 ---
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Roger Eller
Can you make the images referenced from a URL, or must they be included in
the app?

~Roger

On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com wrote:

 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:

 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.

 Though you are not required to fix the following issues, we wanted to make
 you aware of them:

 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.

 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable



 Tom

 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com


 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Roger,

I was hoping to have to avoid that. It seems that 80 MB is the max limit which 
seems crazy to me. I can't seem to reclaim any of the memory from reducing from 
2048 down to 1024 and that bother me. I was hoping to find out why that is 
happening. But I will have to rewrite this to reference the images to get this 
down below 80 I think.

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:

 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Colin Holgate
The file size will be based on the JPEG settings more than just the image size. 
If you have an external folder of your images, how big is the folder if the 
JPEG quality is 60% instead of 80%?



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Colin, This were all PNG files.


-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 2:31 PM, Colin Holgate co...@verizon.net wrote:

 The file size will be based on the JPEG settings more than just the image 
 size. If you have an external folder of your images, how big is the folder if 
 the JPEG quality is 60% instead of 80%?
 
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
Sh_t, what is the address that I want to link these images to in the engine:

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Colin Holgate
Well, you'll need to change that!

On Jun 3, 2013, at 2:32 PM, Thomas McGrath III mcgra...@mac.com wrote:

 Colin, This were all PNG files.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Scott Rossi
I wonder if there's something else going on with the size limitation.  I 
routinely download games that are 300, 400, 500MB in size all the time (even 
more sometimes).

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design

 Original message 
Subject: Re: First App rejected for odd reasons 
From: Thomas McGrath III mcgra...@mac.com 
To: How to use LiveCode use-livecode@lists.runrev.com 
CC:  

Roger,

I was hoping to have to avoid that. It seems that 80 MB is the max limit which 
seems crazy to me. I can't seem to reclaim any of the memory from reducing from 
2048 down to 1024 and that bother me. I was hoping to find out why that is 
happening. But I will have to rewrite this to reference the images to get this 
down below 80 I think.

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:

 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Scott,

If I'm understanding correctly, the limitation is on the actual executable 
inside the app bundle, not the entire app bundle. I too have downloading very 
large apps in the past, but I'm pretty sure these all have their resources 
external to the executable. That's why my suggestion was to pull out all 
possible embedded resources (images, sounds, etc.) and access them externally 
to the executable. Again, I'm not 100% sure this is the issue.

Chris

On Jun 3, 2013, at 1:10 PM, Scott Rossi sc...@tactilemedia.com wrote:

 I wonder if there's something else going on with the size limitation.  I 
 routinely download games that are 300, 400, 500MB in size all the time (even 
 more sometimes).
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
  Original message 
 Subject: Re: First App rejected for odd reasons 
 From: Thomas McGrath III mcgra...@mac.com 
 To: How to use LiveCode use-livecode@lists.runrev.com 
 CC:  
 
 Roger,
 
 I was hoping to have to avoid that. It seems that 80 MB is the max limit 
 which seems crazy to me. I can't seem to reclaim any of the memory from 
 reducing from 2048 down to 1024 and that bother me. I was hoping to find out 
 why that is happening. But I will have to rewrite this to reference the 
 images to get this down below 80 I think.
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:
 
 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: First App rejected for odd reasons

2013-06-03 Thread Thomas McGrath III
I just got finished changing the filename of each image to the referenced image 
and added them to the copy files pane. Then saved the app. Then ran through to 
make sure each was changed from an image to a referenced image. The .livecode 
got  down to 195 MB but the binary is now larger at 400 MB. 

Damn that was a lot of work to not get this smaller. Do I need to delete the 
image and then copy an image object and then set the filename? I just can't 
seem to get rid of the memory originally used up…

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgra...@mac.com

On Jun 3, 2013, at 3:27 PM, Chris Sheffield cmsheffi...@icloud.com wrote:

 Scott,
 
 If I'm understanding correctly, the limitation is on the actual executable 
 inside the app bundle, not the entire app bundle. I too have downloading very 
 large apps in the past, but I'm pretty sure these all have their resources 
 external to the executable. That's why my suggestion was to pull out all 
 possible embedded resources (images, sounds, etc.) and access them externally 
 to the executable. Again, I'm not 100% sure this is the issue.
 
 Chris
 
 On Jun 3, 2013, at 1:10 PM, Scott Rossi sc...@tactilemedia.com wrote:
 
 I wonder if there's something else going on with the size limitation.  I 
 routinely download games that are 300, 400, 500MB in size all the time (even 
 more sometimes).
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
  Original message 
 Subject: Re: First App rejected for odd reasons 
 From: Thomas McGrath III mcgra...@mac.com 
 To: How to use LiveCode use-livecode@lists.runrev.com 
 CC:  
 
 Roger,
 
 I was hoping to have to avoid that. It seems that 80 MB is the max limit 
 which seems crazy to me. I can't seem to reclaim any of the memory from 
 reducing from 2048 down to 1024 and that bother me. I was hoping to find out 
 why that is happening. But I will have to rewrite this to reference the 
 images to get this down below 80 I think.
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:
 
 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url

Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Tom,

What's the actual executable size inside the app bundle? Drill into the app 
bundle and check that. You may be okay, even if the new binary (bundle) size is 
larger.


On Jun 3, 2013, at 1:36 PM, Thomas McGrath III mcgra...@mac.com wrote:

 I just got finished changing the filename of each image to the referenced 
 image and added them to the copy files pane. Then saved the app. Then ran 
 through to make sure each was changed from an image to a referenced image. 
 The .livecode got  down to 195 MB but the binary is now larger at 400 MB. 
 
 Damn that was a lot of work to not get this smaller. Do I need to delete the 
 image and then copy an image object and then set the filename? I just 
 can't seem to get rid of the memory originally used up…
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 3:27 PM, Chris Sheffield cmsheffi...@icloud.com wrote:
 
 Scott,
 
 If I'm understanding correctly, the limitation is on the actual executable 
 inside the app bundle, not the entire app bundle. I too have downloading 
 very large apps in the past, but I'm pretty sure these all have their 
 resources external to the executable. That's why my suggestion was to pull 
 out all possible embedded resources (images, sounds, etc.) and access them 
 externally to the executable. Again, I'm not 100% sure this is the issue.
 
 Chris
 
 On Jun 3, 2013, at 1:10 PM, Scott Rossi sc...@tactilemedia.com wrote:
 
 I wonder if there's something else going on with the size limitation.  I 
 routinely download games that are 300, 400, 500MB in size all the time 
 (even more sometimes).
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
  Original message 
 Subject: Re: First App rejected for odd reasons 
 From: Thomas McGrath III mcgra...@mac.com 
 To: How to use LiveCode use-livecode@lists.runrev.com 
 CC:  
 
 Roger,
 
 I was hoping to have to avoid that. It seems that 80 MB is the max limit 
 which seems crazy to me. I can't seem to reclaim any of the memory from 
 reducing from 2048 down to 1024 and that bother me. I was hoping to find 
 out why that is happening. But I will have to rewrite this to reference the 
 images to get this down below 80 I think.
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:
 
 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com 
 wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which 
 exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App 
 ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit

Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Oops, sorry. Just re-read your message and you stated your stack file is now 
195 MB, which is probably about the size of your executable, plus a few MBs for 
the engine.

Hmm, I'm stumped. Not really sure what else to suggest. This does seem like a 
silly limitation. I admit, though, I've never sent an app this large before. 
What else is making it so large?


On Jun 3, 2013, at 1:36 PM, Thomas McGrath III mcgra...@mac.com wrote:

 I just got finished changing the filename of each image to the referenced 
 image and added them to the copy files pane. Then saved the app. Then ran 
 through to make sure each was changed from an image to a referenced image. 
 The .livecode got  down to 195 MB but the binary is now larger at 400 MB. 
 
 Damn that was a lot of work to not get this smaller. Do I need to delete the 
 image and then copy an image object and then set the filename? I just 
 can't seem to get rid of the memory originally used up…
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 3:27 PM, Chris Sheffield cmsheffi...@icloud.com wrote:
 
 Scott,
 
 If I'm understanding correctly, the limitation is on the actual executable 
 inside the app bundle, not the entire app bundle. I too have downloading 
 very large apps in the past, but I'm pretty sure these all have their 
 resources external to the executable. That's why my suggestion was to pull 
 out all possible embedded resources (images, sounds, etc.) and access them 
 externally to the executable. Again, I'm not 100% sure this is the issue.
 
 Chris
 
 On Jun 3, 2013, at 1:10 PM, Scott Rossi sc...@tactilemedia.com wrote:
 
 I wonder if there's something else going on with the size limitation.  I 
 routinely download games that are 300, 400, 500MB in size all the time 
 (even more sometimes).
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
  Original message 
 Subject: Re: First App rejected for odd reasons 
 From: Thomas McGrath III mcgra...@mac.com 
 To: How to use LiveCode use-livecode@lists.runrev.com 
 CC:  
 
 Roger,
 
 I was hoping to have to avoid that. It seems that 80 MB is the max limit 
 which seems crazy to me. I can't seem to reclaim any of the memory from 
 reducing from 2048 down to 1024 and that bother me. I was hoping to find 
 out why that is happening. But I will have to rewrite this to reference the 
 images to get this down below 80 I think.
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:
 
 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com 
 wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which 
 exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App 
 ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription

Re: First App rejected for odd reasons

2013-06-03 Thread Chris Sheffield
Another thought. In the standalone settings, are you building a universal 
binary? I may be wrong about this (can anyone verify?), but if you're building 
for iOS 5 or later, you should be perfectly safe selecting armv7 only and 
building for that, since any devices capable of running iOS 5 and above are 
armv7 devices only. This may also reduce the size of your executable.


On Jun 3, 2013, at 1:36 PM, Thomas McGrath III mcgra...@mac.com wrote:

 I just got finished changing the filename of each image to the referenced 
 image and added them to the copy files pane. Then saved the app. Then ran 
 through to make sure each was changed from an image to a referenced image. 
 The .livecode got  down to 195 MB but the binary is now larger at 400 MB. 
 
 Damn that was a lot of work to not get this smaller. Do I need to delete the 
 image and then copy an image object and then set the filename? I just 
 can't seem to get rid of the memory originally used up…
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 3:27 PM, Chris Sheffield cmsheffi...@icloud.com wrote:
 
 Scott,
 
 If I'm understanding correctly, the limitation is on the actual executable 
 inside the app bundle, not the entire app bundle. I too have downloading 
 very large apps in the past, but I'm pretty sure these all have their 
 resources external to the executable. That's why my suggestion was to pull 
 out all possible embedded resources (images, sounds, etc.) and access them 
 externally to the executable. Again, I'm not 100% sure this is the issue.
 
 Chris
 
 On Jun 3, 2013, at 1:10 PM, Scott Rossi sc...@tactilemedia.com wrote:
 
 I wonder if there's something else going on with the size limitation.  I 
 routinely download games that are 300, 400, 500MB in size all the time 
 (even more sometimes).
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design
 
  Original message 
 Subject: Re: First App rejected for odd reasons 
 From: Thomas McGrath III mcgra...@mac.com 
 To: How to use LiveCode use-livecode@lists.runrev.com 
 CC:  
 
 Roger,
 
 I was hoping to have to avoid that. It seems that 80 MB is the max limit 
 which seems crazy to me. I can't seem to reclaim any of the memory from 
 reducing from 2048 down to 1024 and that bother me. I was hoping to find 
 out why that is happening. But I will have to rewrite this to reference the 
 images to get this down below 80 I think.
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 On Jun 3, 2013, at 2:19 PM, Roger Eller roger.e.el...@sealedair.com wrote:
 
 Can you make the images referenced from a URL, or must they be included in
 the app?
 
 ~Roger
 
 On Mon, Jun 3, 2013 at 2:17 PM, Thomas McGrath III mcgra...@mac.com 
 wrote:
 
 Ok, after upgrading to 5.5.5 and changing the iOS to 5.0 and above I am
 still getting a Binary rejection for Three of the four reasons:
 
 Invalid Executable Size - Your app's executable file
 'GospelOfMark.app/GospelOfMark' is a size of 243446992 bytes, which 
 exceeds
 the maximum allowed size of 80 MB. Abnormally large executable files are
 often the result of using a development environment that stores excessive
 or unnecessary data in the compiled binary. You may need to contact your
 tool vendor for assistance if your app was built with a developer tool
 other than Xcode. If your app was built using Xcode, you may contactApple
 Developer Technical Support if you need assistance.
 
 Though you are not required to fix the following issues, we wanted to make
 you aware of them:
 
 Missing Push Notification Entitlement - Your app appears to include API
 used to register with the Apple Push Notification service, but the app
 signature's entitlements do not include the aps-environment entitlement.
 If your app uses the Apple Push Notification service, make sure your App 
 ID
 is enabled for Push Notification in the Provisioning Portal, and resubmit
 after signing your app with a Distribution provisioning profile that
 includes the aps-environment entitlement. See Provisioning and
 Development in the Local and Push Notification Programming Guide for more
 information. If your app does not use the Apple Push Notification service,
 no action is required. You may remove the API from future submissions to
 stop this warning. If you use a third-party framework, you may need to
 contact the developer for information on removing the API.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position
 Independent Executable. Please ensure that your build settings are
 configured to create PIE executables. For more information, refer to
 Technical QA QA1788 - Building a Position Independent Executable
 
 
 
 Tom
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your

Re: First App rejected for odd reasons

2013-06-03 Thread Dar Scott
If you have a large executable but Apple reports it as very large but not as 
large as you think it is, there might be a field overflow for size.  That 
overflow might set bits in the header that look like flags and can cause 
extraneous rejection messages.  That is, a bug in xcode or maybe LiveCode might 
have set the header wrong.  Just a wild speculation based on problems in 
general, not Apple specifically.  

Dar


On Jun 3, 2013, at 11:25 AM, Thomas McGrath III wrote:

 I just tried to upload a free app to the Apple App Store and was immediately 
 rejected. I have seen some people get some of these warning but I got four 
 reasons and the Binary was rejected as invalid. I am not using Push 
 notification. I am not accessing the UDID. The project is large because it 
 has 2048x1536 images in it for Retina iPad it is 387 MB. I don't know what a 
 Non-PIE Binary is but I am looking it up now.
 
 This was built with Livecode 5.5.4 Any Ideas?
 
 Non-public API usage:
 
 Apps are not permitted to access the UDID and must not use the 
 uniqueIdentifier method of UIDevice. Please update your apps and servers to 
 associate users with the Vendor or Advertising identifiers introduced in iOS 
 6.
 
 Invalid Executable Size - Your app's executable file 
 'GospelOfMark.app/GospelOfMark' is a size of 249868688 bytes, which exceeds 
 the maximum allowed size of 80 MB. Abnormally large executable files are 
 often the result of using a development environment that stores excessive or 
 unnecessary data in the compiled binary. You may need to contact your tool 
 vendor for assistance if your app was built with a developer tool other than 
 Xcode.
 
 Missing Push Notification Entitlement - Your app appears to include API used 
 to register with the Apple Push Notification service, but the app signature's 
 entitlements do not include the aps-environment entitlement.
 
 Non-PIE Binary - The executable 'GospelOfMark.app' is not a Position 
 Independent Executable. Please ensure that your build settings are configured 
 to create PIE executables. For more information, refer to Technical QA 
 QA1788 - Building a Position Independent Executable
 
 ---
 
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 mcgra...@mac.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode