Apps blocking eachother.

[Alkalaer]

Heya.

I’m fairly new in this forum, and as a Corona developer.

I launched an application to Apple App Store for some months ago, and now I am developing a follower (a second app).

On my iPad I have installed (bought from App Store) my first app, lets call it SO1. When SO1 is running, and I go to menu and try to open my testversion of SO2 (the app in development), it just goes blackscreen.

I have to quit SO1 to open SO2, and vice versa.

Does anyone know why this is happening, and how I can fix it?

Regards

[aukStudios]

That sounds strange.

Is SO2 an update to SO1, or is it a completely new and separate app?  Are you using anything in common between them, such as the bundle ID (including a wildcard bundle ID)?  Did you build SO2 with a separate provisioning profile?

When SO2 opens with a black screen, are there any helpful error messages in the console log?  (To see the console log, consult this blog post: http://www.coronalabs.com/blog/2013/07/09/tutorial-basic-debugging/)

• Andrew

[Alkalaer]

Sorry about the late answer, had another project deadline sneaking up on me.

SO2 is not an update to SO1, but a seperate standalone application.

I started my work on SO2 by copying the codebase from SO1, and changed the content in the build.settings file. But I am not specifying any Bundle ID, since I read somewhere the Provisioning Profile would take care of that.

I made a specific new Provisioning Profile for SO2, which I am fairly sure I used for building the app.

Nice tip about the console log from device! Didnt know that. I’ll test it later on today. Without console log from device, I can only say it gives black screen, not popping up with any Runtime Error alerts.

Regards, and thanks for helping out!

[ksan]

How about the database (if any)? Is it shared?

[Alkalaer]

They are not using any database, but Im writing files into the sandbox. I assume every app has its own sandbox on the iPad aswell as in the simulator?

[aukStudios]

Yes, every app has its own sandbox, so there’s no way your two apps could be sharing resources.

Were you able to see anything in the console log?

My best guess is that it has something to do with your provisioning profiles and bundle IDs, especially if you’re using a wildcard bundle ID.  It might be worthwhile for you to specify the bundle ID in build.settings using they CFBundleIdentifier key, just in case.

• Andrew

[Alkalaer]

I only just got the chance to test on device again, and got this from the console log:

Aug 23 11:28:55 ORMS-PAD amfid[226] \<Error\>: Aug 23 11:28:55 SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName] Aug 23 11:28:56 ORMS-PAD amfid[226] \<Error\>: entitlement 'aps-environment' has value not permitted by a provisioning profile Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Warning: Libinfo call to mDNSResponder on main thread Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Warning: Libinfo call to mDNSResponder on main thread Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Runtime error ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:631: calling 'send' on bad self (udp{connected} expected, got userdata) stack traceback: [C]: ? [C]: in function 'send' ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:631: in function 'sendConsoleMessage' ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:639: in function 'print' ...arkehou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/director.lua:53: in main chunk [C]: in function 'require' ?: in function 'require' ...s/bjarkehou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/main.lua:15: in main chunk Aug 23 11:28:56 ORMS-PAD kernel[0] \<Debug\>: launchd[225] Builtin profile: container (sandbox) Aug 23 11:28:56 ORMS-PAD kernel[0] \<Debug\>: launchd[225] Container: /private/var/mobile/Applications/1C2BF4E7-8F56-492B-B3D9-42DEA73C8F83 (sandbox)

So now the error has been found! First step 

Im not entirely sure what to make of the error message though. It seems it is some kind of problem with the provisioning profile, as Andrew mentioned. Im feel quite confident I used two different profiles to make them, but I’ll go ahead and try again.

Really hate this provisioning profile system!  :unsure:  :mellow:  

[aukStudios]

Are you using Cider to build the binaries?  Try building the binaries directly from Corona, without using Cider or any other IDE.

Also, it looks like you might be using socket connections to communicate with DropBox?  I suppose that’s a way that the two apps, even though they’re in separate sandboxes, could conflict with one another, i.e., if they try to communicate with DropBox on the same port, or something along those lines.

You might also want to try deleting and recreating all your provisioning profiles, and making sure you sign them with the right certificate.

• Andrew

[Alkalaer]

I will try to build without cider as soon as possible.

The Dropbox part of the file path is not connected to the code. My files are just located in Dropbox for version control and backup, since I am the only developer in this project

And I just went through all my profiles and assured they where set up correctly. I have not tried with my Distribution profile for SO2 yet though. Dont know if it could be because of that in any way?

When Im building with my dev-profile, Im getting this error as well:

codesign\_wrapper-4.1: using Apple CA for profile evaluation

But it disappears when Im building with the distribution profile, so I usually just ignore it.

Btw, thanks for helping out

[SegaBoy]

Definitely a Glider/Cider issue, seen it before - in the latest version of Glider you want to build using the Hammer icon as this strips out the Glider functionality from the build. I get this issue if the Corona simulator is booted twice.

[Alkalaer]

I have always been building from the simulater, by the shortcut Cmd + B, which I would assume bypasses the Glider files?

Anyways, it has become to complicated for me to test this, so I am going to put it on the App Store, and test it live, and in case it does not work, I will apply some kind of fix. I will let you guys know of the outcome, once it has been validated from Apple and I’ve tested it my self :-) 

Thanks for the help so far!

[aukStudios]

That sounds strange.

Is SO2 an update to SO1, or is it a completely new and separate app?  Are you using anything in common between them, such as the bundle ID (including a wildcard bundle ID)?  Did you build SO2 with a separate provisioning profile?

When SO2 opens with a black screen, are there any helpful error messages in the console log?  (To see the console log, consult this blog post: http://www.coronalabs.com/blog/2013/07/09/tutorial-basic-debugging/)

• Andrew

[Alkalaer]

Sorry about the late answer, had another project deadline sneaking up on me.

SO2 is not an update to SO1, but a seperate standalone application.

I started my work on SO2 by copying the codebase from SO1, and changed the content in the build.settings file. But I am not specifying any Bundle ID, since I read somewhere the Provisioning Profile would take care of that.

I made a specific new Provisioning Profile for SO2, which I am fairly sure I used for building the app.

Nice tip about the console log from device! Didnt know that. I’ll test it later on today. Without console log from device, I can only say it gives black screen, not popping up with any Runtime Error alerts.

Regards, and thanks for helping out!

[ksan]

How about the database (if any)? Is it shared?

[Alkalaer]

They are not using any database, but Im writing files into the sandbox. I assume every app has its own sandbox on the iPad aswell as in the simulator?

[aukStudios]

Yes, every app has its own sandbox, so there’s no way your two apps could be sharing resources.

Were you able to see anything in the console log?

My best guess is that it has something to do with your provisioning profiles and bundle IDs, especially if you’re using a wildcard bundle ID.  It might be worthwhile for you to specify the bundle ID in build.settings using they CFBundleIdentifier key, just in case.

• Andrew

[Alkalaer]

I only just got the chance to test on device again, and got this from the console log:

Aug 23 11:28:55 ORMS-PAD amfid[226] \<Error\>: Aug 23 11:28:55 SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName] Aug 23 11:28:56 ORMS-PAD amfid[226] \<Error\>: entitlement 'aps-environment' has value not permitted by a provisioning profile Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Warning: Libinfo call to mDNSResponder on main thread Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Warning: Libinfo call to mDNSResponder on main thread Aug 23 11:28:56 ORMS-PAD SO2[225] \<Warning\>: Runtime error ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:631: calling 'send' on bad self (udp{connected} expected, got userdata) stack traceback: [C]: ? [C]: in function 'send' ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:631: in function 'sendConsoleMessage' ...ou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/CiderDebugger.lua:639: in function 'print' ...arkehou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/director.lua:53: in main chunk [C]: in function 'require' ?: in function 'require' ...s/bjarkehou/Dropbox/Work/S√∏de Ord 2/SO\_2\_0/main.lua:15: in main chunk Aug 23 11:28:56 ORMS-PAD kernel[0] \<Debug\>: launchd[225] Builtin profile: container (sandbox) Aug 23 11:28:56 ORMS-PAD kernel[0] \<Debug\>: launchd[225] Container: /private/var/mobile/Applications/1C2BF4E7-8F56-492B-B3D9-42DEA73C8F83 (sandbox)

So now the error has been found! First step 

Im not entirely sure what to make of the error message though. It seems it is some kind of problem with the provisioning profile, as Andrew mentioned. Im feel quite confident I used two different profiles to make them, but I’ll go ahead and try again.

Really hate this provisioning profile system!  :unsure:  :mellow:  

[aukStudios]

Are you using Cider to build the binaries?  Try building the binaries directly from Corona, without using Cider or any other IDE.

Also, it looks like you might be using socket connections to communicate with DropBox?  I suppose that’s a way that the two apps, even though they’re in separate sandboxes, could conflict with one another, i.e., if they try to communicate with DropBox on the same port, or something along those lines.

You might also want to try deleting and recreating all your provisioning profiles, and making sure you sign them with the right certificate.

• Andrew

[Alkalaer]

I will try to build without cider as soon as possible.

The Dropbox part of the file path is not connected to the code. My files are just located in Dropbox for version control and backup, since I am the only developer in this project

And I just went through all my profiles and assured they where set up correctly. I have not tried with my Distribution profile for SO2 yet though. Dont know if it could be because of that in any way?

When Im building with my dev-profile, Im getting this error as well:

codesign\_wrapper-4.1: using Apple CA for profile evaluation

But it disappears when Im building with the distribution profile, so I usually just ignore it.

Btw, thanks for helping out

[SegaBoy]

Definitely a Glider/Cider issue, seen it before - in the latest version of Glider you want to build using the Hammer icon as this strips out the Glider functionality from the build. I get this issue if the Corona simulator is booted twice.