Quote "The daily build drop down box for SDK will no longer appear. All users should be building with this moving forward. Backwards compatibility is unchanged for the moment and should still theoretically support 4.3 and up, though actual "
Does this mean - even if I upgrade Xcode to iOS 6, that users with lower iOS versions will be able to run the app?
Joakim [import]uid: 81188 topic_id: 31191 reply_id: 331191[/import]
In theory, people with devices running iOS 4.3 and later will be able to run your apps built with Corona SDK 919 and XCode 4.5.
At some point Apple will drop support for iOS 4.3 making 5.1 the minimum OS supported. At that time Corona will update and also drop support for 4.3, but for now, 4.3 is still valid.
Keep in mind that if you upgrade your test devices to 6.0 you can no longer see your “print” statements in the console log of the device and at some point (hopefully in the very near future), Corona will address that, but in doing so, it the prints will be delivered by NS_Log which writes to the Mac’s console log, not outputting to the terminal as it does now.
[import]uid: 19626 topic_id: 31191 reply_id: 124728[/import]
An easy way to check is to open the built .app, go to info.plist, and scroll down to MinimumOSVersion and see what is supported. Using Daily Build 914, it states 4.3 regardless of Base SDK chosen. [import]uid: 134101 topic_id: 31191 reply_id: 124729[/import]
@Rob - Hmmmm, whats the Mac’s console log? Never heard of it 
Joakim [import]uid: 81188 topic_id: 31191 reply_id: 124731[/import]
Go up to Spotlight (search) and type in “console” with out the quotes of course. Your first hit should be an app called “Console” and launch it.
OS-X is a variant of the Unix based MACH Operating system (a port of the BSD branch of Unix, not the AT&T System V branch). Regardless, Unix stores various log files in /var/log on the file system.
Servers, dameons and other background running processes are assumed to not have access to the three standard “files” that every Unix process opens by default. These are STDIN, STDOUT and STDERR. STDIN is for a foreground running program usually the keyboard and STDOUT and STDERR (standard output and standard error) are assumed to write to the terminal. Since Unix lets you redirect output from one program to another (pipe), it’s not always the screen and keyboard.
For instance, the following command line command:
ls -l | grep main.lua
would take the output from a directory listing and pipe it through the “grep” filter to look for lines that match the string “main.lua”.
The ls command doesn’t take any input, its output, written to the STDOUT file gets redirected to grep as its input. Some really cool stuff.
But what if, there was an error with the ls command? You wouldn’t necessarily want that output going into grep as input, so error messages get written to a 2nd output channel which in this case is the terminal. This lets developers separate the two types of output.
Background processes, like say the Apache web server, or a MySQL database server typically close the three standard files so they can run cleanly in the background and as such they need a place to dump their messages. Unix provides a library of code call syslog which lets processes write out to various files in /var/log for people to look at later when they need to see what’s up with these background processes.
Apple OS-X and in particular iOS extend this metaphor. In OS-X since it’s Unix, foreground running apps, like Corona SDK are assumed to have a terminal available to it and apps can just print to stdout (what the print() api call does). Servers will use the built in logging (and for OS-X apps, they use NS_Log) to write to the various files in /var/log.
However in iOS, Apple doesn’t want apps spewing output to their Documents directory and there is no terminal to manage input/output to the app.
I’m guessing pre-iOS 6, they trapped the output to STDOUT and STDERR and redirected that output to the device’s console log. But with iOS6 that went away and now only stuff written out by NS_Log ends up in the console log.
This is the file you see in Xcode’s Organizer when you click on the Console Log for that device.
The Xcode Simulator has for the longest time only output to the files in /var/log and using the OS-X app “Console” is how you saw those messages. So now you have to use it to see Corona’s errors and eventually your print statements.
This probably WAY more than you asked for, but I’m in a writing mood right now…
[import]uid: 19626 topic_id: 31191 reply_id: 124733[/import]
Ok, quick question. Do I *have* to update my Mac config to XCode 4.5 in order to compile Corona apps that can run on iOS6? If I put in the new default png, and use letterboxing and adjust for the extra space, won’t the app compiled with the older XCode still run on iPhone 5 with no problem? [import]uid: 160496 topic_id: 31191 reply_id: 124742[/import]
I’m not sure if you have to update your Xcode, but it is a good idea. If you update your device to iOS 6, Xcode 4.5 will be more required. If you don’t upgrade, let us know how it works out.
For “tall mode”, you must be using Corona that is building for the iOS 6 SDK, irrespective of which Xcode you have installed. Do not try to enable “tall mode” using the 5.1 SDK. Bad things will probably happen on iOS 6 devices.
[import]uid: 7563 topic_id: 31191 reply_id: 124779[/import]
Ok, I need some clarification then please.
When I build using build 918 and pick the “iOS 5.1” option, it builds fine with the adHoc provisioning profile or with appstore distribution profile, either one.
When I build exactly same code using 919 (and am forced to build to iOS6), it conks out with the “Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone DistributionCertificate. (-19011)”.
OS version is 10.7.3
XCode version is 4.3.3
XCode Organizer shows that the profiles are valid.
I cannot update XCode to 4.5 right now because it requires OS to be 10.7.5 and higher, and my software update refuses to update (the Mac is running in VMWare which probably has something to do with it).
So - what can I do?
[import]uid: 160496 topic_id: 31191 reply_id: 124799[/import]
Fall back to 918.
[import]uid: 19626 topic_id: 31191 reply_id: 124802[/import]
rob, for now, definitely, but going forward what should be done? Will updating to Mountain Lion and XCode 4.5 fix things?
Basically - what is the reason this is happening? Why would certificates that work when built to iOS 5.1 fail when building to iOS 6? [import]uid: 160496 topic_id: 31191 reply_id: 124809[/import]
Update: I finally managed to update the OS (instead of “Software Update” had to download the update off Apple’s web site and install it). Then installed XCode 4.5. Crossed fingers and ran build .919.
Success! Not only did .919 build ok, but for the first time ever the Corona on the Mac in VM actually ran and showed the app running in the simulator (used to be just blank screen). I guess the new OS update had better OpenGL drivers.
So, for the record, you can run Corona latest builds on VMWare using Mac Lion ver 10.7.5 and everything will work including running the app in the simulator. [import]uid: 160496 topic_id: 31191 reply_id: 124827[/import]
In theory, people with devices running iOS 4.3 and later will be able to run your apps built with Corona SDK 919 and XCode 4.5.
At some point Apple will drop support for iOS 4.3 making 5.1 the minimum OS supported. At that time Corona will update and also drop support for 4.3, but for now, 4.3 is still valid.
Keep in mind that if you upgrade your test devices to 6.0 you can no longer see your “print” statements in the console log of the device and at some point (hopefully in the very near future), Corona will address that, but in doing so, it the prints will be delivered by NS_Log which writes to the Mac’s console log, not outputting to the terminal as it does now.
[import]uid: 19626 topic_id: 31191 reply_id: 124728[/import]
An easy way to check is to open the built .app, go to info.plist, and scroll down to MinimumOSVersion and see what is supported. Using Daily Build 914, it states 4.3 regardless of Base SDK chosen. [import]uid: 134101 topic_id: 31191 reply_id: 124729[/import]
@Rob - Hmmmm, whats the Mac’s console log? Never heard of it
Joakim [import]uid: 81188 topic_id: 31191 reply_id: 124731[/import]
Go up to Spotlight (search) and type in “console” with out the quotes of course. Your first hit should be an app called “Console” and launch it.
OS-X is a variant of the Unix based MACH Operating system (a port of the BSD branch of Unix, not the AT&T System V branch). Regardless, Unix stores various log files in /var/log on the file system.
Servers, dameons and other background running processes are assumed to not have access to the three standard “files” that every Unix process opens by default. These are STDIN, STDOUT and STDERR. STDIN is for a foreground running program usually the keyboard and STDOUT and STDERR (standard output and standard error) are assumed to write to the terminal. Since Unix lets you redirect output from one program to another (pipe), it’s not always the screen and keyboard.
For instance, the following command line command:
ls -l | grep main.lua
would take the output from a directory listing and pipe it through the “grep” filter to look for lines that match the string “main.lua”.
The ls command doesn’t take any input, its output, written to the STDOUT file gets redirected to grep as its input. Some really cool stuff.
But what if, there was an error with the ls command? You wouldn’t necessarily want that output going into grep as input, so error messages get written to a 2nd output channel which in this case is the terminal. This lets developers separate the two types of output.
Background processes, like say the Apache web server, or a MySQL database server typically close the three standard files so they can run cleanly in the background and as such they need a place to dump their messages. Unix provides a library of code call syslog which lets processes write out to various files in /var/log for people to look at later when they need to see what’s up with these background processes.
Apple OS-X and in particular iOS extend this metaphor. In OS-X since it’s Unix, foreground running apps, like Corona SDK are assumed to have a terminal available to it and apps can just print to stdout (what the print() api call does). Servers will use the built in logging (and for OS-X apps, they use NS_Log) to write to the various files in /var/log.
However in iOS, Apple doesn’t want apps spewing output to their Documents directory and there is no terminal to manage input/output to the app.
I’m guessing pre-iOS 6, they trapped the output to STDOUT and STDERR and redirected that output to the device’s console log. But with iOS6 that went away and now only stuff written out by NS_Log ends up in the console log.
This is the file you see in Xcode’s Organizer when you click on the Console Log for that device.
The Xcode Simulator has for the longest time only output to the files in /var/log and using the OS-X app “Console” is how you saw those messages. So now you have to use it to see Corona’s errors and eventually your print statements.
This probably WAY more than you asked for, but I’m in a writing mood right now…
[import]uid: 19626 topic_id: 31191 reply_id: 124733[/import]
Ok, quick question. Do I *have* to update my Mac config to XCode 4.5 in order to compile Corona apps that can run on iOS6? If I put in the new default png, and use letterboxing and adjust for the extra space, won’t the app compiled with the older XCode still run on iPhone 5 with no problem? [import]uid: 160496 topic_id: 31191 reply_id: 124742[/import]
I’m not sure if you have to update your Xcode, but it is a good idea. If you update your device to iOS 6, Xcode 4.5 will be more required. If you don’t upgrade, let us know how it works out.
For “tall mode”, you must be using Corona that is building for the iOS 6 SDK, irrespective of which Xcode you have installed. Do not try to enable “tall mode” using the 5.1 SDK. Bad things will probably happen on iOS 6 devices.
[import]uid: 7563 topic_id: 31191 reply_id: 124779[/import]
Ok, I need some clarification then please.
When I build using build 918 and pick the “iOS 5.1” option, it builds fine with the adHoc provisioning profile or with appstore distribution profile, either one.
When I build exactly same code using 919 (and am forced to build to iOS6), it conks out with the “Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone DistributionCertificate. (-19011)”.
OS version is 10.7.3
XCode version is 4.3.3
XCode Organizer shows that the profiles are valid.
I cannot update XCode to 4.5 right now because it requires OS to be 10.7.5 and higher, and my software update refuses to update (the Mac is running in VMWare which probably has something to do with it).
So - what can I do?
[import]uid: 160496 topic_id: 31191 reply_id: 124799[/import]
Fall back to 918.
[import]uid: 19626 topic_id: 31191 reply_id: 124802[/import]
rob, for now, definitely, but going forward what should be done? Will updating to Mountain Lion and XCode 4.5 fix things?
Basically - what is the reason this is happening? Why would certificates that work when built to iOS 5.1 fail when building to iOS 6? [import]uid: 160496 topic_id: 31191 reply_id: 124809[/import]