I have several applications in the Windows store and I've stopped supporting some of them.
I don't want to just unpublish them or make them unavailable, but completely get rid of them.
How can I permanently remove them so that their names can be reused again by others.
Thanks,
robcsi
Currently, for the app you have never submitted to the Store, you could click Delete this app in the upper right corner of the App overview page, which also releases the reserved name so that you and someone else can use it. However, you’re not able to delete an app from your dashboard once it’s been published. You can make it unavailable or select Hide this app and stop selling in the Distribution and visibility section.
If you just want to reuse the name of them, you don’t need to permanently remove them. You could go to the Manage app names page in the App management section for any of your apps in the Windows Dev Center Dashboard. You can click Delete to remove the name you want, which means this name will immediately be available for someone else to reserve and use.
But please note that your app needs to have at least one reserved name. So you might have to reserve a new name for them before deleting the old one.
More details, please see Manage app names.
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.
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.
The MSDN page for CurrentApp.appId is here.
In a typical application the property comes back in the format 00000000-0000-0000-0000-000000000000, and precisely that number if you're running an app that is not in the Windows store.
Once in the Windows store, it gets a real number, and my question is: Is there anything that would cause an appId to ever change? Perhaps as versions of the app are updated, or if the app is renamed?
The AppId will not change unless you remove the existing app and republish.
I do not have a source for this, but it is the same process from the Windows Phone Marketplace/Store. The ID is used in many places.
The direct link (URL) to your app
Used by the Store app to identify which apps have an update
Used by Visual Studio when creating/uploading packages
...
Changing the Global Unique Identifier is totally against the point of a GUID. If it changed, many things would break. The ID does not change when updating the app, it remains the same.
Is it possible to load up another application when the first application enters the background?
Say I have application 1 and application 2 installed.
When application 1 enters the background, the method is called to invoke the loading of application 2, but application 2 is never loaded.
Is it possible that Apple have disallowed this sort of thing?
I am 100% sure that the custom URL schemes I'm using are able to be called as I have done testing within MobileSafari to make sure they work.
Should mention this is for an iPad application and not iPhone application. Albeit, I don't think there should be much difference between the two when it comes to this issue...
EDIT
Let me explain. The application itself is for a specific purpose. What we want to do is allow our clients to set a setting that will allow the application to "bounce" back via another installed application.
We want to limit the users of the application to only be able to use the application in question. This is due to the fact that the iPad's using this application will ONLY be using this application. Hence why we want to lock it down as best we can.
This will not work, simply because the application can only have the system open URL schemes while in the foreground. Think of it like this, if your application is not in the foreground can it, say, present a modal view such as a UIAlertView or a simple Modal View Controller?
Also, you would be horribly breaking Human Interface Guidelines and would most likely be rejected. URL schemes, especially custom ones, should only be called when the user prompts.
Sounds to me like you want a lockdown/kiosk iOS system. There's simply no way to do this and make it work like they want without breaking out of apple's sandbox. Jail breaking. Or, write one application with two halves. The initial half with authentication or whatever, then the secured half. Maybe we need more context, but as you describe it, URL schemes are incredibly easy to circumvent or fail altogether. What happens when they just delete the goto app?
Now why would you do that? Say the user is getting a call and he proceeds to take it. He definitely wouldn't want to go to another app in between. Other case considered, he would actually leave your app to go to another app he wants to attend to without being taken to another app in between.
I would like to be able to change the OSX services that my application provides based on the current user's preferences (like adding more, changing the name,...). This basically means modifying the Info.plist (NSService key), but I don't think it is a good practice when an application modifies its own Info.plist while running, right? (At least based on few searches here). Is there any other option how to get this functionality?
I guess it should always be an external entity who does modify the Info.plist? So far I can only think about providing a system preference bundle which will do the modification in the actual app? Do you have any ideas?
Thank you
One way would be to install a service in ~/Library/Services that provides the services, and edit that application's Info.plist from your main application.
Of course, that should be an explicit action, so the user (hopefully) knows to delete the service if they delete your application. And you should document that procedure on your product's support web page, just in case they don't.
Here's a small twist to the previous recommendations, create a separate app that handles the service and bundle it within your Resources. When you want to enable the service, instead of copying the file over to ~/Library/Services, create a symbolic link within the ~/Library/Services folder that points to the app you bundled in your Resources.
This way if the user deletes your application, all that will be left behind is a symbolic link pointing to an invalid location. Does less arm than actually leaving the app behind and will have the added benefit that the service will no longer be available (since the info.plist will have been removed when the user deleted your app).