I don't know if this began commensurate with the release of iOS 9 or Xcode 7.1, but for the past week or so, my app updates (which I am beta testing through TestFlight) that I upload to iTunesConnect are not being automatically pushed out to my test team. Anyone seen this as well?
Update 1: I don't know if it is coincidental, but when (and only when) I go to iTunesConnect, select the app I am testing, then select the TestFlight tab, does the update get pushed...huh?
Just wanted to chime in and say that this is also occurring with some of my applications. We had one application test build not go out for 2 days because we didn't try to login to iTunes Connect.
Not entirely sure what is going on at Apples end, but it's definitely a weird bug...
The Apple servers have been slow the past couple days effecting many different areas such as submitting apps, etc.
Related
I am experiencing a strange issue.
New app version was released to appstore, containing new variable stored in user defaults and some minor updates. technically, we are creating new variable, which is an array of values in user defaults, and appending some items in the array. For append, we are using values which were already in place in the previous version (e.g. user_id, device_id and one more string parameter, all 3 were received from backend on 1st registration).
It was (obviously) tested before release. Testing strategy:
A. We were building adhoc old version (say #1) and new version (say #2), installing v1 on the devices and updating it to v2 (by simply downloading new adhoc v2 and installing it on top of v1).
Then, we published v2 to appstore, and issued one more test:
B. We were building same adhoc old version (say #1) installing v1 on the devices and updating it from the appstore, by
B.1 in-app update functionality - following the link to appstore and
B.2 just downloading most recent version from appstore.
Both were fine and both are still fine. Works perfectly.
Now, users are reporting old appstore-installed v.1, updated from appstore to v.2, is crashing after update (almost immediately when it is started).
Only difference we can observe is that when tested, appstore version was installed over adhoc, and now it is appstore over appstore.
Was anybody ever facing the same issue? What is the difference in update process "adhoc -> appstore" versus "appstore -> appstore"? Could it be related to the fact that appstore update is cleaning up all the info from user defaults and thus we need to repeat the application reg process (get all the data again like in the first clean install)?
I still have no crash reports in hand, so I am asking for some advices which can help me to solve the issue faster.
Thanks everyone in advance!
...looks like the issue is linked to GoogleUtilities: we have v7.2 in our current build, however previous build was of v7.4, and - as I found out recently, there is an issue related. TWIMC see https://github.com/google/GoogleUtilities/pull/37 for details.
It is still TBC now, we'll be checking in the next 1-2 days, and I will post some updates here. If indeed related to library version, then it has nothing to do with the app distribution (whatever if it is adhoc or appstore based).
How do I test restoring a purchase with the new .storekit in Xcode 12? When I call SKPaymentQueue.default().restoreCompletedTransactions(), it goes straight to paymentQueueRestoreCompletedTransactionsFinished(_ queue: SKPaymentQueue) with 0 transaction.
There is not a single mention of "restore" in this 25 minutes WWDC video, nor this documentation article also from Apple, nor in any of the handful tutorials on the Internet. What's even more puzzling to me is I can cannot find any complains/questions regarding this?!
I feel like I have gone mad. It would be great if someone can shed some lights. Thanks in advance!
Just to confirm for people who find this via search: There is no way to unit test restoring purchases via the new Xcode 12 StoreKit Test tools (SKTestSession and related).
The best you can do (again, as of early 2021) is to test this stuff the old fashioned way:
Make a sandbox purchase
Delete the app off your test device
Reinstall the app
Use your app's restore purchases button
Manually confirm the purchase was restored
Fingers crossed for WWDC this year...
We have a Android and iOS version of our app. The number of active users on iOS is aproximately 25% of the active user on the Android app.
It happens that the count of Daily New Users of the Android app is always far less then the iOS's. And the this number does not seems to match the increase in Daily Active Users.
The app is br.com.bb.android.
Anyone has an idea of what may be causing this?
Would be great if someone in the Fabric team could take a look into this.
Mike from Fabric here.
For apps where they may come pre-installed or not be opened for a length of time, then the installs may not be counted as a daily new user.
A new user will only be counted if the time between downloading the app and opening it (with foreground activity) is less then 7 days.
I want to change my app from a paid version to a free with ads. However, I don't want the people that originally paid for the app to get the ads.
I was thinking I could include a new update that has extra code that sets up some UserDefaults saying the version doesn't have ads and then do the update to the free version. But that doesn't seem like a very reliable solution.
I think, it depends on minimum OS version, that your program can be run on. For iOS 5.0 and later you can try to use iCloud to store some flag about purchased version. It allows you to set this flag not only for one device, but for the user's account.
Or you can store this info in the keychain to get it later. But in this case your user will not be able to have no ADs on some other device with his(her) account.
Anyway, as far as I know, you need to create an update for your app first to write this flag anywhere. And only in some time make an update with ADs.
I will be glad to see comments if someone has another thoughts about this issue.
It seems there is no reliable method to detect whether someone paid for your app or downloaded it later when the price has been changed to free. For this reason I have decided to create two separate entries in the app store.
I've updated my iPhone app to support the iPhone 5 screen..
I've done this before for another app and I was forced to upload new screenshots taken with the iPhone 5.
This time however, iTunes Connect just displays the status as "waiting for review" and isn't mentioning anything about the screenshots..
I'm slightly worried something has gone wrong? App works great on iPhone 5 and simulator though.
It turns out Apple can block apps during the review process that have something wrong with metadata. If they decide your metadata is wrong they'll just change your app's status to "Metadata Rejected".
Here's the quote from the rules for this status:
Appears when specific metadata items aside from your binary have not
passed review. To resolve the issue, edit the metadata in iTunes
Connect and your existing binary is then reused for the review
process. You receive a communication from App Review in the Resolution
Center regarding the reason for the metadata rejection.
When things change to the AppStore (Apple adds a device) they might require you to get new screenshots. But if nothing changed in their system, it's normal that they don't ask.
Don't worry!
They copy over the screenshots from your last version of the app (or is your Retina4 screenshot section in itunesconnect empty?). So if you don´t want to update them, it should be okay like this.
Chances are your app has not hit review (and now as of the 21st) and won't be reviewed until after the 29th. Once your app hits review, it will become rejected for the missing screenshots. If you want to save yourself some time and pain, update the screenshots while Apple is on their downtime for the Christmas holiday. You'll thank yourself later.
My app got accepted yesterday, no word about the screenshots.
App works fine on iPhone 5, mailed Apple to complain this probably is a bug (iTUnes Connect does not recognize localized Default.png, which is what is checked to verify it is iPhone 5 optimized I believe.)