I'm currently beta testing one of my apps via testflight but im having problems with the installation process.
Everything works fine up to the point, when one of my testers tries to install the app. After you tap install the downloading process stops at about 80%.
If you minimize Testflight the app appears to be installed and can be used but the UX is poor.
In Testflight the app remains in the 80% install state:
If i install my app via xcode everything runs fine under iOS8.
In my case, I discovered on a hunch that the CFBundleVersion should not contain leading zeros after a period.
15.06011812 should be 15.6011812
Once we fixed that, the installs completed in the UI of TestFlight (then the switch for the watch app showed up and worked).
Afterward, I found this answer searching for 'testflight progress'.
TestFlight thinks that it never finished installing because the CFBundleVersion in the installed app's Info.plist contains the leading zero which makes it an older version of the app. When I quit TestFlight and relaunched, it thought that there was an update available.
Until I tried installing the Watch App this was just an annoyance in the UI, but then it was preventing me from seeing the switch to install the Watch App.
Related
have you had the following error in TestFlight? Basically, we have test versions in TestFlight that when we launch them to external testers work. But it has happened to us 2 times that after a week or two, that version stops working.
Basically, the app won't open, won't even show the splash, and crashes.
Last week the app stopped working for all testers, we updated to a new version and it started working fine for them again. But yesterday the version that already works previously began to fail them again.
Today, I just generated a new version with no code changes and it works. But I'm afraid it will eventually start to fail.
When I say that it fails, it is that the app icon is touched, it tries to open, but it does not open and it crashes.
For example, now the new version works fine for me, but if I go to TestFlight and install a previous version that worked fine on my phone 2 days ago, it no longer works for me.
Any idea what could be going on, guys?
Maybe some certificate expires or I don't know, any idea is welcome.
I'm using expo managed workflow and eas build to generate the iOS app.
Something that happens with the versions that start to fail is that when they are installed, the first time it does not fail. But if I completely close the app and reopen it again, it doesn't open anymore, and the crash occurs.
We're using Sentry, but we don't have any issues. But I have this crash in TestFlight errors.
Thank you in advance for all your comments or ideas.
I have a testing and production release channel, on TestFlight and the App Store, respectively. I want the ability to run both on the same device. Otherwise if there is an issue with my testing release channel me and my beta users are blocked from using the working production channel (as least without constantly downloading and overwriting the TestFlight vs App Store versions)
I tried https://medium.com/#ywongcode/building-multiple-versions-of-a-react-native-app-4361252ddde5, but it seems like most of the configurations were reverted on build, and I wound up with the same bundleIdentifier and therefore I could not download the TestFlight testing version without removing the App Store version.
I think your best bet is to release multiple apps from 1 source code. We ran into this problem as well and ended up releasing separate test (internal testing), beta (external testing) and production apps. Each with their own app logo, app name and expo release channel. As far as I know, there is no way to switch release channel after your app has been built.
Alternatively you could (beta) test your app by pointing your users to https://exp.host/#username/yourApp?release-channel=. This way your testers can test most of your app’s functionally in the Expo Go app.
You can use iOS Build Configurations and Android Build Variants to easily create different apps within one project.
Ok, I have a problem with expo build. Please let me know if you need more details. Basically, the project I am working on is NOT detached. It is just using Expo.
So I publish it. Let's say the javascript bundle version is 0.17, and I am publishing a breaking change to 0.18.
When I load the app from Hockey App, the javascript bundle is clearly not 0.18 because I don't see my breaking changes. Then, I close the app and re-open it, and the JS bundle is updated.
The build script is:
exp build:android
[exp] Android:
[exp] APK: [AWS LINK] apk has been generated, it took 0 seconds
Then, I get an AWS link to the APK, which I download and upload to Hockey Apps.
How should I diagnose this problem?
Exp version is 44.0.0
It is the way it works in Android. First time you open your app after you publish, the code is downloaded in background. Next time it will run the new code.
Quoting the documentation:
Updates are handled differently on iOS and Android. On Android, updates are downloaded in the background. This means that the first time a user opens your app after an update they will get the old version while the new version is downloaded in the background. The second time they open the app they’ll get the new version. On iOS, updates are downloaded synchronously, so users will get the new version the first time they open your app after an update.
I just upgraded to xCode 4.3 and used it to generate a new revision of an iPad app about 50 beta testers have been using for several months. I distributed the beta app through TestFlight as usual.
Most testers upgraded with no problem, but several testers are getting the TestFlight message "You have not permitted this device to install this build" when they try to install the new rev. I've never seen this message before. Their iPad UDID is definitely in the build's embedded.mobileprovision file and everything was working working fine with the prior revision.
What am I -- or the testers -- doing wrong and how do we correct it?
Hi i experienced the same and it seems that you must generate your mobile provisioner profile from Xcode(instead of Apple dev site for example) and you should update your App permissions (TestFlight) with this same provisioner profile that you just generated on your machine so basically the machine that generates and archive the apps using Xcode must generate the provisioner profile and then you should update your testflight app permissions with this file.
Does that make any sense?
Hope this works for you testflight is really nice to use, i faced same problems with all of my apps and hardware devices (testers all around the world)
Thanks
Turns out this is apparently a bug in Testflight. I tried to resolve the issue through their support forum and multiple emails with no real answer. I did not want to switch services as my testers knew the Testflight system well. But eventually switched to Diawi. My testers were able to install the app using Diawi with no problems.
I've got an Xcode project that I've been working on over the past few weeks.
I just made some changes to an embedded framework that I'm working on (recompiled, to be specific) now, however, I am unable to launch the application in the simulator.
The app hangs on "Attaching to [app name]," if I have a debugger on. If I don't have a debugger on, Xcode just says the app has finished running.
There is no icon installed on the device.
Here's what I've done so far:
Restarted
Reset simulator
Clean and build
Deleted derrived data
I cannot install onto a device either, but then I get an error:
Error launching remote program: No such file or directory (/Users/peter/Library/Developer/Xcode/DerivedData/x-gtwuuwmavjonyrcxjmpcletdpyjw/Build/Products/Debug-iphoneos/x.app/x).
Oddly enough, what worked was installing another app in the sim (just launched another project and ran it) and then launching the other app in the sim.
I'm not sure what the issue was, but I tried it on two computers and it was hanging on each, so it was related to the project rather than the simulator. There's an issue to think about...