I need to know if I have to wait for another review proccess after I already did it and my app is now in Pending Developer Release.
The point is I need to keep it in [PDRelease] mode until my testers say everything is ok, publish it.
But it has no sense if the app is approved and waiting "manual release" and then I need to resend it to another review or better called: "Beta testing review".
Thanks!
As far as I know that is correct, they are two separate workflows... If you had submitted the build to be approved for public beta testing and submitted it to the store at the same time you would be in a different place. Whether or not behind the scene it checks the work flow value to see if its pending release and short circuits the review is completely opaque as far as I know.
Related
We have uploaded an update of our existing app (WASFAT) as internal testing build. We can access it successfully.
Now I want to leave from the internal testing and want to access the live build.
There is not leave button the playstore wasfat page. Please have a look at the attached image.
When we have released beta version, we had that leave button. But in the internal release, we don't have it.
How can I get out from this internal testing mode? How can I access the original live build? Also I don't want to remove my id from play console internal testing.
Thanks for any suggestions
As far as I know, you can opt-out of internal testing with the same link you used to enter in the internal testing program. Also, you need to remove your email from internal tester. However, It will take some time to be able to access live mode again
The simplest way I have found is to just switch to a different account within play store.
Open play store afresh
On top right, tap your account icon (or where ever it is located)
Click the drop down and tap "Add another account"
Later on it is just a matter of selecting an account, no password entry needed if done before.
The advantage of this is that you don't have to wait for Googles services to register that you have disabled a testing account. When you need to enable the testing account you will have to wait again. So this is pretty nifty for me.
I'm reliably able to restart my phone, and have changes to beta status reflected immediately.
Pardon all the italic shouting. Just trying to emphasize key points. Please note that the existing post iOS app submission and beta review process does not answer this question.
The following sequence of events does happen and it's what I expect:
Create a new version (number) of app in iTC
Archive and upload app to iTC
Internal testers get notified to download with TestFlight
Submit for Beta Approval (critical for next step)
Now all testers (inside & out) get notified to download
But next:
Create a new build (number) in Xcode
Archive and upload to iTC
Only internal testers are notified. ⬅︎ unexpected
Do I need Beta Approval every time I want the external testers notified? I could swear this has not been the case. But of course things may have changed. Or it's just my bad memory.
Do I need Beta Approval every time I want the external testers notified?
NO
I could swear this has not been the case. But of course things may have changed. Or it's just my bad memory.
It's just that:
1) there's a short delay (5-20 minutes) before you can send to external testers
2) from time to time Apple's servers are screwed, and the 5-20 minute delay becomes "many hours".
Change the version number - you have to wait for a (presumably human) approval: takes 1-2 days
Change the build number - only a short delay for a (presumably) automatic check.
And don't forget you have to manually release to the external testers each time!
You need to approve first build of every new version.As Apple mentioned" A review is only required for the first build of a version. Subsequent builds may not need a full review.."https://help.apple.com/itunes-connect/developer/#/dev3bfa33892
Beta review is only required for the first build and the first build send in after a 90 day period.
Lets say I have a build uploaded to iTunes Connect that has had a status of "Waiting for Review" for 10 days. If I submit a new build will my app go to the back of the line and have to wait another 10+ days or will I still be in line to get reviewed very soon?
Yes, after you Reject Binary then upload a new one, this puts your app to the back of the line again.
Edit: see this answer, this answer, the later answer on this question and Apple's own dev guide.
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
I've also experienced it myself, although that was years ago.
If you reject your binary, you will remove your app from the Review queue. If you then submit a new build, you will unfortunately be placed at the end of the line.
We know this from experience, and it's also indicated by Apple (emphasis mine):
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
I have the requirement to close the application after 10 minutes if the user has not interacted with the application.
All the questions about this are related to the session time out, the problem here is that the application has no security and is a requirement to run it without connectivity.
Any idea about how to implement this?
Thank you.
First of all, as I mentioned in the comments above, this is a really bad user experience. You should tell your customer you just don't do something like this to your users. never.
If I understand you correctly, the application is running offline, meaning it does not connect to the Worklight Server...
So you should probably just maintain some counter... if the user does any action in the application (touch a button, whatever), reset it. If no action was done and 10 minutes have passed, called WL.App.close.
Please note that using WL.App.close in such a manner in iOS can make your application be rejected from the App Store if found.
My Windows 8 app needs to run a background task triggered by the receipt of raw notifications sent from Windows Phone 8 apps. Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
http://dotnet.dzone.com/articles/windows-store-app-development-10?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fdotnet+%28.NET+Zone%29
Normally, the user has control of whether they will allow an app to be a lockscreen app or not. In my case, though, it must be such or be basically braindead. So, can I enforce that: IOW, inform that users "Install this as a lockscreen app, or don't install it at all"?
What I mean is: assuming the user retains ultimate control, will letting them know that the app won't work well without them allowing it to be a lockscreen app cause it to fail certification?
You bet, that's how it's done.
Want to force them to allow it? Disable the "Block" button. (just kidding, you can't)
Remember, it's your app.
Check out how the Store app "supports" snap view. That's a nice example to show certification requirements can be "met" at the bare least implementation.
When you read the cert reqs. read them literally.
Responding to that event to invoke a background task is apparently only allowed for lockscreen apps:
Not exactly true. But anyway, the short answer to your question is no. And in reality, I can't see why the user would want to use your app, if it were to constantly do things in the background and thus drain their battery-life, for no good reason.
You might want to detail what your app actually will do, for more accurate advice.
No, only the user decides what is, or is not, on their lock screen. Because a user decides what is on the lock screen app list, apps preferably should provide a decent degraded experience if they are not on the lock screen. Messaging can be provided in the application to make the user aware of the degraded experience, but again, it is ultimately up to the user.
To answer your question "will it fail certification" no. You can programmatically request that the user promote your app to the lock screen when you run, but you should consider degrading gracefully if they don't. (E.g. register for a timer event to give your app some time to periodically update itself, or send a notification through WNS and handle it then.)
While it's great to assume that your users will want to run your app under the lock screen, providing a consistent, delightful experience under different conditions is what will set you apart.