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.
Related
I'm trying to send my app to External TestFlight testers. All the tutorials mention that I should be able to add external testers via an External Testing tab on the left hand side. I don't see this option.
I tried filling in all the details in "Test Information" but I still don't see the section.
How do I see the External Testers section for my app?
I resolved this by creating an Internal Testing group first. After doing this, I was able to see the plus sign near the External Testing header on the left hand side.
Note: There's also a chance that I didn't need to create this group, and simply waiting 15-30 minutes caused it to appear.
I have a question regarding executeJs function.
page.executeJs("$0.click();", downloadAnchor.getElement());
This line of code is not working in real iPhone Safari browser, though it works in mobile responsive mode from desktop safari. Appreciate your help on this
Browsers will be "suspicious" of anything starting a download that isn't a direct reaction to interaction by the user. This is done as a security precaution since starting to download files without the user's explicit consent can be dangerous in specific cases. Different browsers and configurations have different policies for exactly where to draw the line.
In your case, the download isn't started as a direct consequence of user interaction but instead as direct consequence of receiving a message from the server. This kind of pattern will simply not work reliably no matter what you do.
Instead, you need to design the interaction so that the download is directly triggered by the user. The easiest way of doing that is by having the user directly click on the actual download link. If you want to have some indirection, then you still need to make the action work directly in the browser without going through the server.
I'm submitting my first app through iTunes Connect. It is a social networking community so I have to provide a demo account for the submission. My app already has a live database of users as there is currently an active web version.
I'm new to this and confused as to how I should handle this. Should I be creating a demo account that will not show up in any other live user's search results? Are the testers going to be attempting to interact with other live users? I am assuming I will need to show the various functions of the app, like messaging and events. In that case should I be creating a few "demo" users for the testers to interact with?
Alternatively, should I be linking them to the development version and development database? If that's the case, then the build that I send them would only be a development build then?
I am confused on how this is supposed to work and can't seem to find any information to help?
In my experience, you'll need to give them the production version that will go into the store. So not the development build.
When we submit an app for approval, it seems to get installed and activated on a couple of devices, but nothing much ever happens. They barely use it, as far as we can tell. We can tell that it's installed and run. We have previously been rejected when the network connectivity wasn't working right, so we know that they do look at the app after it's installed.
I'd suggest you make them an account that looks relatively anonymous (or even "Test Account" which you real users are hardly likely to try to interact with). You could create another account and say "If you want to send a message, send it to account xxxx". We've never had them interact with our app enough to utilise the suggestions we've made.
If you have an active / inactive flag, you could think about making these accounts inactive once the app is approved, then re-activating it when you next want to submit your app.
The new iTunes Connect distinguishes between the internal testers (maximum of 25) and external testers (maximum of 1000).
At various points they say that newly uploaded builds are automatically distributed to internal testers via the test flight app, and this has usually been my experience. But sometimes I see a menu like this, indicating that I need to select "Invite Testers" in order for it to be visible to internal testers:
What causes this?
When it does this, I cannot distribute my build to my internal testers, and it seems like iTunes Connect is failing to recognize that my project already has internal testers.
We've been experiencing this too. A hack that works for us sometimes is turn the TestFlight Beta Testing switch off, then wait for that to take effect, then turn it back on, and it usually pushes the latest out to the internal testers.
Turning the "Test Flight Beta Testing" switch off and back on will indeed change the "Internal" column to Active. As #will suggests. The problem is that if you are already approved for External delivery, this will also cause the external testers to go back to the Submit For Beta App Review again, so use this work-around with care.
I'm working on an OS X app that most users choose to "launch at login", the kind you'd find at the menu bar.
In order to launch it at login I'm using SMLoginItemSetEnabled to launch a LoginHelper app that will open the main app, as described in this tutorial.
The app is failing to start up at login for just a handful of our users.
I was unable to reproduce this or to track the cause but I found (on a user's machine) that:
Deleting /Root/_com.apple.SMLoginItemBookmarks/[myapp] and /Root/[myapp] on /var/db/launchd.db/com.apple.launchd.peruser.$UID/overrides.plist and then resetting the Launch at login on the app fixed the issue. Also, we diff'd the files and the Data on the bookmark had changed.
For reference, I found about the overrides.plist here.
Since the app has both a Mac App Store and a Direct download version, I'm suspecting multiple copies of the app setting themselves as Launch at login may be the reason for this to fail, maybe these "bookmarks" are trying to open another instance of the app, that may or may not be deleted.
Now the questions, provided that this app needs to remain sandboxed:
Is there a way of updating that Data on the overrides.plist bookmarks?
Is there any way of deleting one self's app from the overrides.plist to start clean?
Is this maybe a known issue?
Any other suggestions on why the bookmark seems to point nowhere or how to fix it will be appreciated.
Note: This is my first question on StackOverflow, please excuse me if I failed to follow some of the suggested etiquette.
I don't know a definitive solution to this, I wasn't even aware of the overrides.plist. It could be related to multiple copies. As far as I understand, adding login through SMLoginItemSetEnabled sets a metadata flag that this Bundle ID should be launched on start. Then Spotlight, on start, will go do a metadata search on the file system and see which Bundle IDs need to be launched. Then, I guess, it will initiate the launch using the bundle ID. In my own application, Trickster, which uses the same technique for launching, I see that if I enable launch-on-login through the app itself, it might pop-up this strange message which refers to a debug build. I'm not even sure why it says about the first time. Very strange.
So, to have them launched, you have to make sure that the relevant bundles are in locations where Spotlight indexes (that the user hasn't disable Spotlight for these locations). Usually users don't disable Spotlight, especially for /Applications/ but I'm just saying.
What I usually suggest when support comes my way (and how I have it set up for me because I have multiple copies), is I to disable launch from within the app and instead add the correct one (from /Applications) manually in Login Items in System Preferences.