I am using Firebase App distribution over a year now to deliver my Flutter app releases to my testers and it's working fine by following this process :
Open XCode and make a release of the app
upload the .ipa to Firebase app distribution
If the testers download it the first time, add their device to my apple dev account
Make a new release with the new provisioning profile
The testers are able to download the release
Now i am using flutter 3.7 and i am using this command :
flutter build ipa --obfuscate --split-debug-info=/Users/foxtom/Desktop
It's working very fine apparently, i do have a .ipa file generated etc..
However, when i upload this .ipa coming from this command, all my testers (including myself) are getting Device is registered, all set ! from Firebase app distribution.
This is the message you get when the device is registered the first time and that you have to make a new release... So i have made 3 different releases after this one and the message remains the same.
Note : if i do the same release using Xcode, it's working fine.
I can't figure out if the issue is from Firebase or Flutter here... My guesses are :
Flutter doesn't take in consideration my provisioning profile
Firebase app distribution has an issue "veryfying" obfuscated builds
I have raised a ticket to Firebase support in the meantime, but i would like to know if someone had already experienced this and if there is a current solution.
EDIT : i have created a flutter issue to get more insight
Related
I'm trying to create interval test for my flutter app.
But Google Console is not publishes the new version of the app for testers.
I'm NOT publishing the app for the first time.
I have a previous version of the app that was approved.
However this is my first test for the app.
I strictly followed the instructions provided by Google.
What I did:
made a new release that I want to test
created internal test
added list of internal testers (all of them are approved now).
published the new version to internal test
copied the link and tried to get the test version of the app as an internal tester.
However I've downloaded the old version of the app.
I've also tried to create alpha and beta testing after that and provided them with new version.
But still got this problem.
What's more, I did some extra step to solve this problem:
cleaned Play Market cache on the device
downloaded another simulator to test the app
changed the version of the app and downloaded it again
deleted and added again tester list in Google play console
Screenshots:
https://github.com/asg1997/qu/blob/main/Screenshot_1639590890.png
https://github.com/asg1997/qu/blob/main/Screenshot_1639591139.png,
https://github.com/asg1997/qu/blob/main/Screenshot_1639591150.png,
https://github.com/asg1997/qu/blob/main/%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA%20%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0%202021-12-15%20%D0%B2%2020.53.20.png,
https://github.com/asg1997/qu/blob/main/%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA%20%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0%202021-12-15%20%D0%B2%2020.54.18.png
I have an flutter app for ios and can build it for the app store using:
flutter build ios --release
But how can I build an Ad-Hoc app for ios?
Pre-requisite
Apple Developer Program membership ($99/year)
Distribution certificate added to your machine
In the Xcode project (Signing & Capabilities tab), select your team/ developer account which has the Apple Developer program membership.
1. Create an Archive (.xcarchive)
Technically you do not build an Ad Hoc app, you build a debug/release/profile app, which you then distribute via a distribution method, one option is Ad Hoc.
Using command line: You can run flutter build ipa to build the xcarchive. Then it should show a URL for your Runner.xcarchive at the output (double click that link), or
Using Xcode: Open the Xcode project, and in the menu bar, click Product > Archive. The organizer window will open once the archive is complete.
2. Create an .ipa
Now the Organizer window should be open. Press the Distribute App button: you should see multiple options. You can share the .ipa file with users, and they can install it onto their iPhone:
It's worth noting you can also create an .ipa using xcodebuild, but when you're first learning, it's nicer to use Xcode.
3. Install the .ipa on a device.
I wrote an answer about that: https://stackoverflow.com/a/68968301/7365866
Reminder
Just remember to do this:
Action Required: You must set a build name and number in the pubspec.yaml file
version field before submitting to the App Store.
You can use Code Magic's CLI tool to achieve that.
On their CLI (locally installed or on your CI server), there is an option to add
--type IOS_APP_ADHOC
See at the end of their signing documentation section for Specifying code signing configuration
You can use --export-method in the flutter build command, example:
flutter build ipa --release --export-method=ad-hoc
For Someone out there, who have trouble building ios application since they don't have an apple developer account, here's a method that i do and i use.
1st if you are an ios user you can connect your ios device into your mac and do a flutter run --release. you can also do it with just the simulator too and it does works the same.
Now, the ios app is created, using your 7 days free trial developers provisioning profile, what we need is to use some programs likie imazing,apple configurator or itunes, to get the ipa from inside the app.
Now you have build the ios app with a release version, and you can redistribute it with just a 7 days free trial version of yours.
I signed up for TestFlight.
Then I followed all steps in this tutorial:
But Xcode throws this warning:
Application failed codesign verification. The signature was invalid,
contains disallowed entitlements, or it was not signed with an iPhone
Distribution Certificate. (-19011)
It smells like there is a lot more work to do than what they wrote in the tutorial.
Is there a complete tutorial which walks through every step without stepping over anything?
And do I need to add the SDK even for simple beta tests?
(Edit: No, SDK is not needed!)
Start with logging into the Provisioning Portal, and adding a test device or two, under Devices. Then go to Provisioning and create a new one for the appID you are working on and add those devices.
Back to Xcode and use the Organizer:Devices:Provisioning Profiles to download (refresh) the Provisioning Profile. Set your project's Debug scheme's signing to use that developer profile. You should then be able to build and then archive. Once archived, do an ad hoc distribution and save off that file to the desktop.
Go to your account on TestFlightApp.com and press the Upload Build button. Drop the file you saved on your desktop, into the Build upload area. TestFlightApp will give you errors if the app wasn't bundled for adhoc or signed properly.
Now, here is where TestFlightApp.com will save you work. Send out invites to friends from within TestFlightApp.com. TestFlightApp.com will manage notifying them and as they create an account, it will also help them find their UDIDs. These UDID's can be batched up and later downloaded by you and re-uploaded to the Apple Provisioning Center, into your devices section.
You then use Xcode to refresh your profiles, and rebuild the app, archive, and upload to testflightapp. Then you can select which one of your testers will get to see this build and what message they should be sent. Your testers will not have to figure out how to download the files and install them using iTunes or other app, they merely press the install button.
Believe me, while it is still a bit of work, it is so much better than not using TestFlightApp.com, especially if your users are not very savvy about app installation. In the future, you can use the TestFLight SDK to gather crash reports and usage information for your debug builds.
See the following for some more info: TestFlight beta-testing iOS app
I have an iPhone App which is available on App Store.
Now I have made some changes in my existing App which can be tested only when an App is available on App Store.
So I want to release newer version but I want to test it first before it it available on App Store for all users
And once it is tested and if it works fine as per expectation then only I want to make it available for other user.
How can I do that?
The short answer is: NO - there is no way to make an app available on the app store that only you can download and test.
If you can specify exactly what it is that you are trying to test that only works when the app is live, we may be able to suggest a different approach.
EDIT: if you just want to test the upgrade process, you can just install the new version on top of the old one - there's no need to delete the one already on the phone. For example if you download the version from the app store, run it, and then build and install a version from Xcode, it will install on top of the app store version, and keep all the settings and documents from that version, just like if a user was upgrading.
Also read up on "wireless distribution" for adhoc apps. Using wireless distribution, you can download and install the app from a link on your phone, just as if you were doing it from the app store, except the link will only work for UDIDs that were included in the adhoc profile.
Two choices:
OTA AdHoc Distribution
Set up over-the-air Ad Hoc distribution. These guys can help: https://testflightapp.com/
A user can install an adhoc build over an appstore build without deleting data, and vice-versa.
Side-by-side Builds
Ok, so your question is about side-by-side installation: you want a user to have the real app and a test version on the phone at the same time. To do that you just need to create version of the app with a different bundle Id. So if your app is com.myco.MyApp, create a copy of it as com.myco.testing.MyApp. Then use Ad Hoc distribution (or whatever) to get it to testers.
I've got a build script that updates the bundle version with the build number. I'm actually just about to update the script so that it will modify the bundle Id so I can have side-by-side testing. This is what I do for the bundle version on my build server:
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion '${PROJECTBUNDLEVERSION}'" $PROJECT/Info.plist
Presumably can do something similar for the CFBundleID:
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier '${PROJECTTESTBUNDLEID}'" $PROJECT/Info.plist
I already have an iPhone application (version 1.0) available in the App Store and am ready to submit a newer version (version 1.1). How do I test the new upgrade to make sure that the current sqlite database and property list files on the earlier version do not get deleted/overwritten etc? The new version assumes the old data in both the sqlite database and property lists remain.
Or better yet, is there a resource I can use to walk me through what to watch for when developing an application update?
The way we tackled this when we wanted to test our database upgrade code was to use ad hoc distribution.
We had our testers download the 1.0 app from iTunes and install it on their test devices.
Then we built an Ad Hoc distribution of the app using a configuration based on the Release config, and made sure that it had the same bundle identifier. As long as the bundle identifier is the same, the new app should overwrite the previous version.
We asked our testers to install the ad hoc build as they normally would, by dragging it into itunes and then syncing the device to simulate upgrading.
As far as I know, this is identical to the user downloading and installing an upgrade via the app store on the device itself.
As you'd expect, the documents folder should be left intact, leaving your database in place, and your app should be able to run its upgrade code to modify the database in the way you need.
Hope this helps :)
Test like so:
delete app from device.
install v1.0 app (or .ipa file) into iTunes
sync to device, iTunes will install the app
launch app on device, create and save data, etc.
quit app on device
install v1.1 app (or .ipa file) into iTunes; iTunes will ask to confirm replacing older version of the app.
sync to device, iTunes will update the app
launch app on device
test using existing data with new version of the app.