It’s my first attempt to deploy an iOS app and send an app to the App Store.
After building the app, if I drag&drop it on the AppWrapper, nothing happens. If I use AppWrapper’s “New” command and drag&drop the app to the window that appears, I get an error:
It’s true the Info.plist isn’t inside a “Contents” folder, but it looks to be the default configuration.
What’s happening?
Using Xojo you develop and test your app.
When you are ready to deploy, flip the switch in the IDE to ‘Build for App Store’
You need to have a current Xcode installed, an Apple developer account, and the correct provisions and certificates.
If you do, BUILD the app, and you will get a folder with some stuff including an .IPA file.
Open Transporter app, login, drag your app to that, and shoot it off to Apple that way.
What you CAN do with App Wrapper, is to use the File menu and ‘Check Code Signing Diagnostics’ which might show up missing or invalid certificates
Ah, ok; thanks. I now realise App Wrapper “allows” drag&drop of iOS apps solely because they share the same extension as a MacOS app and can’t distinguish. Still, the behaviour is misleading.
I have them (unless I’m so confused ) but Xojo tells me this while building: “A distribution profile is required when building for the app store.” (again…).
However, I triple-checked the data in the certificates, XCode configuration (used “Manually download certificate”, as well). I think the main issue is that the errors shown aren’t ever explanatory (neither from Apple nor from Xojo, which probably take them from Apple’s tools); each time I create a new iOS Xojo project, something goes weird with this system (even just debugging on a real device is harder than it should be).
Looks simpler than what I’m trying right now: using App Store Connect. I’ve just found Transporter app (thank you for the hint), but Xojo currently builds me an app bundle; no IPA, even inside the bundle. Could the build error mentioned above be the cause of a missing IPA?
You only get the IPA if you have the IDE set to 'Build for App Store’
“A distribution profile is required when building for the app store.” (again…).
However, I triple-checked the data in the certificates, XCode configuration…the errors shown aren’t ever explanatory …each time I create a new iOS Xojo project, something goes weird
Amen.
The forum won’t allow me to use the words that I would like to describe the process by.
Every year without fail, when I try to update an iOS app, I find I get these kind of errors, which take weeks to resolve by deleting, re-requesting, downloading .
I hate it with a passion and I am frankly sick and tired of the complexity and fragility.
It’s mostly Apple’s fault (we don’t need all this palaver… just let us put an app on a device!)
, but if you build with Xcode all this is handled transparently for you. It ‘just works’.
Apple have no incentive to make it easier for Xojo, and Xojo don’t make it easy for us.
Have you requested, created , downloaded , and double clicked a suitable distribution profile?
Hey Arnaud,
Mac Apps and iOS apps are not the same, so App Wrapper would have to undergo some form of transition. I did put feelers out at one time to gauge how much interest there would be, and I got disappointing results.
Thanks. While it’s true I’ve learnt some things there, I still believe I have done what’s required .
When I look in my keychain, under “my certificates”, I’m seeing one entry named “iPhone developer: (me)” which contains a single entry which corresponds to another app already approved on my testing device. Shouldn’t this entry also contain the app I’m trying to approve now, or it’s just a “placeholder” from when I initially put the certificate the first time? (there’s no other “iPhone developer” entry and, when I double-click the certificate for the current app, nothing happens (only Keychain opens)).
Thanks for the information, Sam. I don’t know iOS distribution enough yet (obviously…) to know how easy it’ll be without AppWrapper.
Certificates define the people who are allowed to sign things for development or distribution. In the case of a single developer l, you should have one of each, and it should have both a public and a private key associated with it.
Profiles are for the application’s development and there should be a pair of these for development and distribution as well.
The development profile contains three pieces of information:
The Application ID for the app it belongs to
A reference to each of the developer certificates for the people that are allowed to do development builds
The list of hardware devices that the app can be tested on.
The Distribution profile contains:
The application ID
A reference to the Distribution certificate to limit who is actually able to send the app to the App Store
Which profile is used depends on whether you select Development or App Store in the iOS build settings in the IDE.
In terms of Application IDs, don’t use wildcard certs (the ones that contain asterisks). For some reason, Xojo does not choose the right certificate when you do that. It tries (I checked the code myself as an engineer), but somewhere along the way it gets confused.
NOTE: My free profile-lister tool can help straighten these things out if you’re having trouble.
Regarding this error, Xojo is passing through the error that they get when calling codesign. My guess is that you don’t actually have the distribution profile on your machine or that it is somehow corrupt. I suggest that you go back to your account, download that profile again, double-click the file to install it and see if you get any errors during that process.
If you’re using my tool, make sure you’ve created an App Store Connect API key and entered that info in the prefs screen. (The instructions for doing that are available by clicking the help button on that screen. ) Letting the tool see your account contents allows it to diagnose more stuff.
Right; I tend to mix them a bit.
BTW, a “.mobileprovision” file is a profile, correct?
In the Keychain, I have five certificates that matches my needs:
• iPhone distribution (for AppStore submission)
• iPhone developer (which contains a single entry: a previous app I was able to transfer to my iPad)
• Developer ID Application
• Apple Distribution
• Apple Development
They all have a private key. Public keys are listed in the “Keys” tab but it’s a mess to map them to the private keys (some don’t match).
Am I correct that profiles don’t show in either XCode nor in the Keychain?
I can see them only on the developper.apple.com website or as my “.mobileprovision” downloaded files. Neither prove I’ve installed them successfully (although I always double-clicked them once downloaded).
As far as I’m aware, I filled these pieces. I triple-checked.
What I can see, that is troubling me since the beginning, is that the “.mobileprovision” files’ App ID start with my developer ID (i.e. instead of just “com.amug.raljokios”, it’s “(my developer ID).com.amug.raljokios”). Can this confuse Xojo or it’s rather expected?
Since I have to put on the Apple Store (for only around 7 persons), I chose “App Store” in the IDE.
I’ve avoided them.
It’s still possible the IDE is still confused in my case. It would be nice if it could let us choose a specific certificates when it’s confused.
I’ve actually looked for it yesterday, but the links I found were broken. I thought you may have removed the tool since then .
It’s fairly possible my issue is about misunderstanding. The only non-development profile I have in my account is of type “App Store”. When I go to add a new profile, there are 6 choices (Ad Hoc, tvOS, App Store, tvOS App Store, Mac App Store, Developer ID), so I conclude my “App Store” profile is already a “distribution profile”. (I tend to avoid creating too much “dummy” profiles, could they interfere each others).
Tried that again right now: when I double-click the file, XCode comes to front and nothing seems to happen. Xojo still reports the same issue.
Correct. Profiles are not visible in either of them. Technically they’re files on disk… but my Profile Lister app does show them.
That’s not a problem. Apple does this because they cannot guarantee that two developers won’t choose the same app ID. By prefixing with the account ID, they’re just making sure that they’re unique.
You should only ever have one certificate for yourself as a developer and for your team for distribution. The only time you should have more than one of each on your machine is when one of them is expiring and you are transitioning to a new one. The IDE will chooses which certificate to use based on the provisioning profile that is in use.
In terms of profiles, you’ll have more success if you only have one of each (dev & list) per application ID, and the IDE finds more than one, it will always choose the ones that expire last.
It’s called Profile Triage now and is available for download from my website. I decided to have a single source for this instead of the 20 or so dropbox links that I’ve created over the years.
Ironically, that’s the exact correct behavior. Xcode will show an error if something doesn’t work, but nothing if it does.
One insanely tricky part of this whole process is that if you also use Xcode (which I’ve been doing a lot lately), it likes to create provisioning profiles locally without actually creating them in your dev account. So for instance, here’s what my account looks like in Profile Triage:
The red one at the top with the symbol on the right is the development profile for Profile Triage. When I hover over that, it tells me that the profile has expired which means that I need to go to my account and usually I can just click Edit, Save and just download a new profile.
Now… the two at the bottom are what I was talking about above… those profiles were created by Xcode (notice that one of them is the wildcard cert). Hovering over those two, it says that they don’t actually exist in my developer account, which, if I go to my account, is absolutely true. What I typically do in this situation is right-click on them and select Remove which removes them from disk.
If you’re interested in seeing all these files on disk, you can go to:
~/Library/MobileDevice/Provisioning Profiles
But I would not suggest adding anything manually. They’re just xml files, but they are signed by apple, need to have a particular GUID and will be corrupted by any editing you might do to the file.
I have used App Profile Triage in the past, and it certainly shows up information.
I definitely managed to resolve a few issues last year, my thanks again.
What I have forgotten (if I ever knew), however, is what the things it shows us, actually mean.
And what needs to be done in response if there is an issue.
Greg: Do you have any plans to make a ‘cheat sheet’ or add an info tab?
(eg only by reading the post above did I realise that there might be info if I hover the mouse above a line. )
Probably what I should do is create a Quick Start manual for it. I don’t think there’s enough to warrant a whole manual, but something that shows what all the panels are and how to use it would probably be helpful.
Thanks for all your help, greatly appreciated. There were two settings wrong in my configuration (one of them being the certificate linked to the provision profile, which I chose by guessing among two choices).
I’ve now been able to build the app correctly and sent it using Transporter (a new way for me). I’ll now investigate how to propagate the app using TestFlight.
That’s relatively easy. Go to the app in the App Store and click on TestFlight. Any internal testers (people on your dev team) that you have will get the update immediately. External testers (people you invite via email) will have to wait for Apple to do a basic review before it is available to them.
Thanks for your information.
Since it’s an app that is going to be used once per year (on the week-end of 2 and 3 of September this year) with less than 10 persons, I’m considering keeping the app as a TestFlight release. Once the 90 days are over, I’ll wait for next year to make a new version. I’ll add them as external testers just before the event.
For what it’s worth I was just doing this with a customer last week. The nice part is that as soon as you’ve determined that a version is releasable via TestFlight, you just need to submit it for review.
One important thing I forgot… turn on autoincrement or add a build step that increments the non release value on every release build. The reason for this is that Apple will reject builds with the same exact version number, so if you don’t want to have to change the visible number for each beta, you at least need the non-release number to change.
I also suggest setting it back to zero when you start your next full release cycle.