Change version release control in iTunes connect - app-store-connect

I submitted an app update in iTunes Connect and set the version release control to Hold for Developer Release. I want to change it to release automatically (it is still waiting for review). Is this possible, and if so, how do I make this change?

I've torn through iTunes connect extensively and there doesn't seem to be a way to change an automatic release to Hold for Developer, or a Hold for Developer marked release to automatic release. It seems to be set upon creation of the version and uneditable.
There may be a way to do this by rejecting the binary and starting the process over, but I haven't had a chance to test this as I don't have any pending releases and nothing currently ready to be updated.

Funny, I came across this post yesterday because I needed to change this setting. Today, Apple updated iTunes Connect and it's now possible to change this option right on the binary page.

It seems that you can't, but if you want to you can go to rights and pricing and move the availability date to a later date. Users won't be able to download you app during that time, but the update won't be available to existing users either when new version gets approved.

Related

Accurev: Restore workspace to older version

I'm a brand new to Accurev and I'm having many troubles with it. One of the developers I'm working with has promoted bad code (things are now broken that weren't before) for 2 months on a stream, and I'm wanting to get a copy of the original code before any changes were made to it.
I currently have a workspace, and whenever the other developer creates code, I pull his changes into this workspace attempting to fix the bugs. These changes are promoted to an existing issue within Accurev.
Is there any way I can perhaps create a second workspace and obtain a copy of the original code (before any changes were made)? My target date is March 14th.
I would suggest you revert or demote the bad code that was promoted into the stream (Depending on what version of AccuRev you are using). This would put the stream back into the state it was before the promotion occurred.
Below are some suggested readings on the related topics.
Best way to "un-promote" files in Accurev?
https://community.microfocus.com/borland/managetrack/accurev/w/wiki/26745/purge-revert-and-demote
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/25951/how-to-revert-changes-in-a-stream
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/26079/what-is-the-proper-way-to-revert-by-change-package
As an alternative, you could create a time-based stream below the one with the bad code. Set a time basis that predates the bad promote.
To do this, I right-clicked the stream >> New Snapshot.
I select "Specified" and enter the date (with a relative time).
From the Snapshot, I created a New Workspace which was then populated with previous code.
Hope this helps!

MobileFirst 7.1 - Access disabled for older version, but users are still able to access

Two months back we released latest version of application and disabled all older version using MobileFirst console. But when looking at WRKLGHT.CLIENT_INSTANCES table we have observed that even after 2 months users are still able to access older version. Is this a bug with MobileFirst?
Or am I missing any thing was I suppose to do anything else to completely disable older version.
I have tested this theory based on the mentioned in the comments, where a remotely-disabled device still makes new records in the database - but I do not see any new such records being made (you too also could not reproduce this).
This question really goes outside what can be handled in Stack Overflow and so I suggest to open a PMR and provide server logs, and to attempt to recreate this, as without a recreation there is not much then can be done...

Updating an iPad App with a Completely Different Architecture

I've been updating my iPad app very steadily now and the process has been fine. But in a month or so, I'm going to be upgrading it to a version that has a completely different architecture.
Both versions will be using the cache and db in very different ways to store the data it's pulling from a server.
Question: Will the Apple update process automatically delete all local data from my previous version upon installing the new version? Or, do I have to code this functionality in somewhere in my new version?
Example: Some files you download on Windows don't remove the data from "Application Data" or "Local Settings" upon uninstalling. I fear that this same scenario will happen on my iPad when upgrading my app to a completely new version. Is this the case?
Thanks,
Derek
No, the update process does not delete files that you have in the app's documents folder. They will still be there.
iPhone and iPad updates do not remove data from previous version installations of an app. Your app will have to detect (say, look for the current version number) the old databases, and either delete them, or perhaps better for the user, update them to the new format.
Make sure to somehow tag the new data format with a version number so your app can detect it, and not delete it.

Accurev - why not Auto-Update?

Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.

Testing on blackberry device - adding and removing app multiple times

It would be useful for many people to know how to completely remove an application from your device when testing.
I have downloaded my app many times now, and likewise have deleted it many times. The problem is when deleting the app, it does not remove things like the persistent object related to my app, or the images downloaded through the app. So, when I download the next build, I have no idea if something broke that is related to building the persistent object or fetching the images since those elements already exist from the last build.
I don't know if this is a cache thing. I don't know if this is expected and I have to use some utility to wipe this data after deleting the app. I can't really find much info through basic web searches.
Any information would be appreciated.
Blackberry Bold 9000. 4.6 OS. tested with both SD card and no SD card.
Objects stored in the PersistentStore are automatically deleted on uninstall if their interfaces were defined in your project. If they are from the standard BlackBerry API then they will stick around until they're deleted. E.G if you save a String in the PersistentStore it will stay in the PersistentStore but if you save a class you created it will be deleted on an uninstall. So if you want to have those objects be deleted automatically just create a wrapper class and save that.
Images stored on the filesystem will not be deleted until you or some application deletes them. However, it should be easy for you to write an app that clears everything out.
Another solution you could implement is making your app somewhat self-aware of its data.
Create a simple String value that you persist (or optionally, persist it in a Hashtable so you can store many properties this way) that includes "Version".
At startup of the GUI app, compare the stored "Version" against the application's current version. If the stored version doesn't exist, or if it exists and matches, take no action.
If it exists and does not match, automatically clean up old persisted data; or alternatively prompt the user to see if they want that data to be deleted (which one is better will depend on your implementation)
You can also use CodeModuleListener to listen for an uninstall event -- when that happens, you can clean up at that time as well or instead.
(As an aside and a bit of shameless self promotion, I am actually currently working on a shareable library for Blackberry that makes managing persistence much easier, as well as desktop data backup/restore. I'm doing this as part of the BBSSH project, but I'll be splitting it off into a separate library of core components and publishing it under a dual GPL/optional commercial license. It will contain hooks for data cleanup and data versioning. )