Apple rejects app because test account not given.
As App login via OTP only. How can i manage this situtation?
if you are using Firebase Auth, you can add the test phone number and set the OTP.
on Firebase Console Navigate to Authentication->Sign-in method->phone then add your testing number as in the photo
then provide it to apple in the test account section as in the photo
if you are using another provider, I'm sure they have the ability to provide test phone numbers.
Related
I need to get my iOS app (React Native) get approved to external testers. I am getting this message from Apple:
I know that I should provide login information(username and pass). But I have user's phone number as name and user can enter the pass only after he get the SMS with a security code.
Here's the complete flow:
User enters phone number
Gets SMS with code and enters it
Entering password
Proceeding to app
What should be done in this case? Can the Apple sign up and create the account, if I write a message to them, describing the flow?
Thanks!
Our team faced that too. We solved it by providing them with a demo account.
We set up a phone number and static code to pass to otp. And then we provided them and it worked!
I submitted my app for review to start external beta testing and I got the response:
Guideline 2.1 - Information Needed
...but we are not able to continue because we need a demo account to
fully assess your app features.
The app requires verification by phone number (same as when you install whatsapp), and sends a message to the phone number, but there is no "demo account". Do I need to create an account which they can access, with a phone number, and a pre-set verification code in this case? The app is based on the contacts on the phone, so the "experience" won't work as it would for a user this way.
Thanks!
Yes create a basic demo account that they can login to - Apple is strict about this.
Once you are finished you can either update the information and email them back or handle it through the Resolution Center. I updated the app information in iTunes connect with the demo login information and replied to the rejection email stating the demo account information, shortly after that the app was approved for TestFlight.
They basically just need to be able to see as much as possible within your app, so even if what shows is minimal that is fine.
I can't find any info about my problem - I've written an app, which is sms-based(it means that user has to request and receive sms from my server, and can't continue until enter sms-code and some other things based on sms within app). So, my problem is rejecting from appstore review due to "no demo data", but how i can get it if even "demo" depends on real device?
Apple will test your app on a real device. When they run the app, they need to be able to get past your registration process. So you need to have your system setup so when the reviewer runs your submitted app they can perform what actions your app requires. This means your server needs to be running for real.
If there is some specific information (user id, password, etc.) that the reviewer must enter into your app to use it, you must provide that information in the "Demo account" field for your app's details in iTunes Connect.
I am using facebook iOS ads to send install to my app.
I am using the following code to track the installs.
- (void)applicationDidBecomeActive:(UIApplication *)application {
[FBSession.activeSession handleDidBecomeActive];
[FBSettings publishInstall:[FBSession defaultAppID]];
}
Is there anyway to track that a new install actually came from Facebook? I want to plug it into Flurry and track what quality of user I am getting.
Typically when you track ad providers (be it facebook, greystripe, adcolony, etc) they will record some sort of device identifier for every device that clicks the ad. In the past it was UDID but moving forward Apple is pushing their advertiser identifier.
You will need to store your own list of identifiers for every device that installed your app and then cross reference with the list of devices that clicked on the advertisement. The ad provider should be able to provide this list, including Facebook.
I am not sure if Flurry supports making cohorts by advertiser but I do know Kontagent has some admin tools which allow you to drop in reports from the ad networks to enable tracking by provider. Alternatively you could always roll your own.
There is no way.
You could check wether the user liked your Fanpage or stuff like that, but you don't know the link the user opening the AppStore came from.
A possibility could be to not directly link the ad to the AppsStore, but link it via a private proxy that recognizes a user clicked on the link and if shortly after this time a user downloaded your app it may be a Facebook User that clicked the Ad
I figure you has read the SDK documentation.
If you go to Set up your app to measure mobile app install ads you can read that this information is stored in your App Dashboard.
In this link is explained clearly how the "app installs ads" works and how to manage this information.
Unfortunately isn't possible to export this information directly from your app to be sent to Flurry.
What you're talking about is attributing the source of installs for a mobile advertising campaign. In order to do this, you need to be able to determine that the person who installed the app was the same person that clicked on the relevant ad (on Facebook, or whatever other ad provider). In order to do this, you need an identifier that uniquely identifies the user--in the past this was the UDID, now it's moving towards the advertising identifier.
Many ad providers will calculate this figure for you if you report to them whenever a use installs the app for any reason, by comparing all the identifiers of the installs you send them with the identifiers of the users that clicked their ads.
I am about to submit an iOS app to paypal to get a live App ID. However, the code needs some minor changes. So, I want to know if I can edit my app's code after I apply and get a Paypal app ID? Or, do I have to wait until my coding is done and then submit the app to Paypal?
If your app implementation works well in the PayPal Sandbox, then you are good to go. Most probably PayPal will issue you a Live App ID. All features NEED NOT be entirely functional. Once you obtain your PayPal Live App ID, you can of course make changes to your app, add features to it and fix bugs. Doing so will not void your Live App ID. Keep in mind that any future changes you make to your app will be submitted to the App Store not to PayPal. So technically speaking, PayPal doesn't even know if you made changes to your app or not. The key point here is to make sure your app works well in the PayPal Sandbox -- at all time.
I would also like to clarify one common myth about the Live App ID, for those who are not entirely familiar about what it is. If your App uses the PayPal API, you need a Live App ID before you can test your App on an actual iOS device and/or before you submit it to the App Store. The Live App-ID is provided to you by PayPal, NOT Apple.
To obtain a Live APP ID,
Check your account status. Login to PayPal. Go to your PayPal Profile and click My settings. Confirm that your Account type is either Premier or Business, or upgrade your account.
Check your API settings. Click My selling tools. Expand Selling online if needed and check API access. Click Update and Add or edit API permission or View API signature.
To get your application live, follow the steps outline in Adaptive Apps 101.
Once you've verified that your implementation works correctly in the Sandbox, submit your application to PayPal and you will get your Live App ID.
I assume that by "Paypal ID" you mean "Apple ID that PayPal API uses to identifiy your app", in other words, the numeric ID that iTunes Connect gives you when you set up a new app.
The answer is that iTunes Connect gives you this ID as soon as you set up the app on iTunes Connect (i.e. when you put up the description, icon, screenshots, etc). It's not neccesary to actually submit your app binary to get this ID, and you can change the screenshots and description later, so if they're not ready yet, just upload some dummy placeholders for now.
There should be no problem getting your PayPal API set up with your ID before the app is submitted, but you shouldn't upload your app binary if you still want to make changes (although as it happens, you can reject the binary later and upload a new one if you need to anyway, as long as Apple's not already approved it).