Showing beta versions of an app to a customer - ios

Can I send to my customer a beta version of my iOS app that he can run in the Simulator ?
Can I install Simulator only (without Xcode) on a Mac ?
I actually need an efficient methodology to send him the beta versions of the app, without having to meet him at each update.
Also, (3.) is there a way to install a beta version of the app, I developed in my xCode on its iOS device without app store ?
Thanks

No, I do not believe you can.
No, I don't think so. If you could, however, you'd also have to put all your source code on that machine and build your app there, just to run it in the simulator.
Yes, it's called an Ad Hoc build. You create a special provisioning profile through the provisioning portal on Apple's Developer portal. You then sign the build with that provisioning profile (actually, "Build and Archive"). Then you can, through the Xcode Organizer, share that build via e-mail with your customer. The Organizer creates an .ipa file and includes it along with the provisioning profile into an e-mail message which you can then compose and send.
Edit: The Ad Hoc provisioning profile will, of course, need to include the UDID's of your customer's device(s) on which they would like to test. That is the missing piece here that ties it all together: UDIDs, Ad Hoc profile, signed app with that profile, e-mail it to the customer and they can install both files (ipa and profile) via iTunes.
Lots of documentation on this, right in the Developer portal.

TestFlightApp.com is a great way to easily manage and distribute beta tests and ad-hoc builds. It's nothing you couldn't do yourself, manually, but it really helps make it easy, and is free.

Related

Appcenter iOS install error "this app cannot be installed because its integrity could not be verified"

I see that this question has been asked many times but I see no solution that works for me so I'm hoping that providing more info might shed some light.
We use appcenter.ms to test iOS apps. Until our iOS certificate expired this method worked fine. We generated a new enterprise certificate and ad hoc provisioning profile for new releases of the iOS app. Which led to the first curiosity.
I see how to upload a certificate on appcenter.ms but not a provisioning profile. I thought there was an option to do this in the past but perhaps I am mistaken. However, the app is signed with a provisioning profile before upload, so perhaps this is not needed now.
Once the app is uploaded, it can't be installed. It remains grey and when you tap it, you get the "this app cannot be installed because its integrity could not be verified" error. Again, that the .ipa is created with an ad hoc certificate and profile in Xamarin (VS for Mac).
Also, I can't install the provisioning profile on a device from appcenter.ms. You basically get stuck in a loop where you seem to successfully install the profile but have to keep doing it because it never actually installs.
I hope this is enough info for some insight and thanks in advance for any feedback.
We were able to solve this by redoing and downloading development certs and via
And also downloading and double clicking the apple development certificate here
After that our keychain showed both as trusted and we could build to the iPhone again.
The issue can be the your device is simply not registered on the developer portal and/or that ad-hoc provisioning profiles have not been regenerated.
You need to register your device, regenerate a provisioning profile with this device in it and rebuild your app using this profile.
This can also happen because of
Developer ID Notary Service - Outage
which can be checked on https://developer.apple.com/system-status/
Notarization is well explained here:
Notarization gives users more confidence that the Developer ID-signed
software you distribute has been checked by Apple for malicious
components. Notarization is not App Review. The Apple notary service
is an automated system that scans your software for malicious content,
checks for code-signing issues, and returns the results to you
quickly. If there are no issues, the notary service generates a ticket
for you to staple to your software.
Work around fix:
Select your app.
Navigate to TextFlight tab
Create External Testing group
Add one tester
Add build which you want to download using TestFlight
Open TestFlight and download an app.
In my case this was caused by trying to include an entitlement for aps-environment "development" when using an Ad-Hoc provisioning profile. The value for this environment in Entitlements.plist must match what is hard coded into the provisioning profile file - if you open an Ad-Hoc profile in a text editor you will see it expects the "production" environment.
The possible solutions depending on your requirements are to either use the Development profile/certificate, or change the aps-environment to "production" to continue using an Ad-Hoc provisioning profile.
It can also happen if you have other incorrect entitlements - worth checking what entitlements are enabled under the Identifier in Apple Developer portal and removing unnecessary ones.
I had this issue because when building the app on xCode for distribution (Product->Archive then Distribute App), I chose automatic signing. After manually signing the app and choosing my own generated certificate and profile, everything worked again fine.
I removed the Entitlements file from the Addition Resources in iOS Bundle Signing and it worked.
I think the MSAL configuration was set to debug in entitlements.plist
I have also face this issue before but for me the reason was little different
First the build was enterprise one and the build was made on the earlier Xcode version on which the iOS version you are using on the device was not supported by the Xcode.
All I did was to update my Xcode and make a new build and shared the build. After that we were able to install that build over device Hope it works for you as well
This is how I solved for myself.
In you iPhone Settings > General > VPN & Device Management you should see your company name (if an app from it is installed), and if you click on it, you will see a button like "Verify" above the list of apps installed provided by the company. Just click on "Verify".

After adding new UDIDs to provisioning profile, do I need to rebuild the IPA?

I have an app (adhoc dist.) and uploaded it to Diawi.
Now, I should add new UDIDs. After add them, do I need to recreate or rebuild the IPA and re-upload to Diawi?
Thanks in advance
An Ad-hoc IPA will only install on the devices listed in the embedded provisioning profile. If you want the app to be able to be installed on additional devices then yes, you need to provide an updated IPA with the updated profile.
Better yet, use TestFlight and avoid all of this hassle.
The answer to your query may be in two types of accounts
1) If you have an Enterprise Apple Account: No need to add tester UUDI to the account as the app can be released using Universal distribution binary which any device can install using OTA installation method.
2) If you have the developer account: your existing app will have no impact but yes for the new devices to install you have to regenerate the profile as the existing as on store account portal will get Invalid and needs to be updated for New IPA compilation. The old one will not work.
I would always recommend having an Enterprise account for a testing/building app company as Appstore Developer account is better for Distribution on Appstore or small scale company who rarely adds device ID for debugging and testing unless its standalone developer like scenario.

iOS app Certificaction and ad hoc testing

I work for a company developing their iPad app. None in the company is a technological geek to handle Xcode app deployment themselves. So for now, we do this:
I develop the app.
Create an ad hoc testing version and share the .ipa file with them.
They test and then I make a distribution version for further release.
What I want to establish as a permanent solution is
I develop and share the Xcode archive
They make all different versions for testing and release.
However I have been largely unsuccessful in doing so: for creating the archive, I have to sign/certify with my development profile. They could deploy it further from Xcode archive to an .ipa file, using their distribution certificate. However, they can not install it on their devices. I believe mainly because the development version requires my certificate/profile to be enabled on their devices :(.
Is there a way out? I need to provide them an archive which they could further sign and do whatever they want to do (either test on whatever devices they want to or release).
Thanks,
Nikhil
If you don't want to manage the device identifiers where you are deploying the device, you could use:
1) TestFlightApp.com (although I don't know what the current status of their offerings are -- since they've been acquired by Apple -- but they still have a "Sign Up" link on the top of their home page).
or
2) Apple's Enterprise Developer Program, which allows you to "Distribute In-house Apps".
You can sign application using their distribution certificate.
To do so c'est have to send you a p12 export of the certificate, the p12 contains the private key of the one creating the certificate and the certificate.
To export a certificate :
Go to the keychain access
Right click on the certificate
click export

iOS Developer Builds vs Distribution Builds

I've been under the impression for some time that for iOS, signing a build with a developer provisioning profile allows the app to run (and get debugged) on an authorized device (listed in the development provisioning profile) through an XCode build, whereas signing with a distribution profile allows the app to be run (but not debugged) on other iOS devices that have been specifically added to the distribution provisioning file for the purposes of QA/beta testing/etc (and installed via iTunes sync or OTA distribution), without the need for those QA/beta-testers to even know what an XCode is.
Seems to match several of Apple's own docs:
"When you’re ready to share your app for user testing [...], you need
to create an archive of the app using a distribution provisioning
profile and send it to app testers" (source)
and
Code Signing with a development profile allows your app to run on
device through Xcode, and signing with a distribution profile allows
you to create distribution builds.
The certificate named "iPhone Developer" allows you to run/debug your
app on iOS devices through Xcode, and the certificate named "iPhone
Distribution" allows testing your submission build with Ad Hoc
distribution (source)
This seems to imply that using a distribution profile is necessary to do app sharing outside of the App Store, and for years I've always assumed this to be true. Recently however, I've been shown a use case from another colleague where they've been able to share builds with many other people using only a development provisioning file. Another user has described a similar discovery here: Why not use development provisioning instead of ad hoc?
I'm worried I might be missing something here, I'm now suspicious that there are cases where as long as another user has access to a relevant developer provisioning profile that includes their device's UUID, and installs it on their device (drag into iTunes, config utility, etc), that they would be able to sync Developer builds through iTunes as well, without the need for making separate Distribution builds.
This has led me to question some of the assumptions I've had about the nature of the differences between developer and distribution builds in general. I'm starting to think that it's more about debug support and general ease of installation, rather than the nature of how it's installed (XCode vs iTunes/OTA explicitly).
In short, if a device has it's UUID included in a developer provisioning profile, do I really need to make separate distribution builds, or can I simply share a Release Development build and assume that will work with an iTunes sync as well? Does the "Use for Development" button in organizer have any real relevance to this?
More broadly: what are the fundamental differences between Developer and AdHoc builds in terms of how they can be shared among other people within an organization in the development/testing phase before being submitted to the App Store?
Check this SO Post for the differences listed out between developer and distribution builds. From a developer perspective, there is not much difference whether you want to distribute your app either by signing it with a developer profile or distribution profile, provided you are not testing push notifications.

Archived IPA won't install onto my phone

I've done this a few times before with my own apps.
I've started working for a client and using there account I've created the necessary files on the dev portal. Downloaded and install them on my machine.
Followed the instructions to create an archived IPA for adhoc distribution.
Drag it into iTunes.
Then drag it to my device in iTunes. When i start dragging the app icon a red badge appears, but the app never starts to sync onto the phone.
I opened the ipa and looked at the mobile provisioning file and I see that my phones UDID is
included there.
Can anybody give me some insight into what the problem may be?
I had this happen when I could see myself in the provisioning profile under its code-signing identity but I was not on the distribution profile. And the issue relied on the build settings.
Go to your project -> Build Settings and check under Code Signing. Confirm that you are using the correct developer profile. Pay extra attention to mismatches between bundle identifiers.
Check the validity of the distribution profile in the same area.
Archive and make sure you are using the correct build configuration. When creating the ipa file confirm for the correct distribution profile again.
Hope that helps
There can be many reasons for that. one thing that cross my mind:
Check if their device iOS version is not higher then the SDK you are using or lower then your deployment target.
I can also recommend to use Testflight service (search Test Flight iOS in google), it is perfect for distributing builds to customers.

Resources