after a little bit of advice. Kind of got myself into a bit of a chicken and egg situation.
So they story is, We have recently completed a major update on some mobile apps (Both iOS and Android). These mobile apps connect to a Azure hosted app service which has also had a number of significant changes including many db structure changes. All of which is currently live in production, so I have to release the updated app service and mobile apps at the same time.
This is where the problem comes in. To make the apps avaliable for review with the relevent stores, I will of course mean I need to have updated the app service so that the updated apps work, but I can't update that until I can release the apps to the general user base.
Any advice on how to get the updated apps approved without breaking things for the current users?
You could use Azure web app deployment slot to set up staging environments.
Deploying your application to a non-production slot has the following benefits:
1.You can validate app changes in a staging deployment slot before swapping it with the production slot.
2.Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.
3.After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.
When you have updated the app service so that the updated apps work, click swap and it will immediately swap to production without breaking things for the current users.
For more details, you could refer to this article to set up staging environments.
Related
We have developed a private WP8 application, and we have registered company account on Windows Phone Dev Center.
The next step is the development of "Company Hub app" which will take care for installation and available updates.
Since we have only one application, I think there is no need to develop "Company Hub app".
Is it possible that the application itself check for any available updates? (We plan to develop webservice for upgrades distribution).
Can I do the following:
Application Check for updates
If so, take the installation of a new version
The application installs a new version of itself. (If this is possible, how to do it?)
So far I have managed to find only examples with "Company Hub app"
Thanks
Selvir K
So far I have managed to find only examples with "Company Hub app"
That's because it's the only way.
To deploy applications on Windows Phone, you have three options:
Using the marketplace
Using the company hub: you get the benefits of the marketplace, but inside of your company network
Using the XAP deploy tool. The phone needs to be developer unlocked (it's a free operation now), there is a limit to the number of apps you can deploy this way on a phone, and you lose the benefits of automatic updates
One alternative way could be to publish an app on the marketplace and mark it as hidden. Only people who have the direct link to your app will be able to download it. Still, if the link to the app is somehow leaked outside of the company, you'll have no way to control who installs the app. So don't do that for critical/confidential applications.
I am in the exact same boat. We are working on our fist wp8 app and do not want a company hub.
I found if you use InstallationManager.AddPackageAsync(String, Uri) method within your app this will go to our website and download\install the xap file very easily. Of course once executed it appears to close your app so it can reinstall but for now this works fine for us.
I happened to see this post as I just finished developing a Windows Phone 8 app for a client, which was in a similar situation. I found publishing to Windows Phone Beta Store severed them the best for the moment for the main reasons below.
The distribution is totally in client's control. The apps in beta
store do not appear nor can be searched in public store. Client just need to send
emails with the app link to its employees. Only the people with the
Windows Accounts added into the tester's list are allowed to download
and install it. Up to 10,000 testers are allowed which is more than
enough for most of the business.
It is much easier to publish it in beta store compared to it is in the
public one. It does not require strict certification as it does in public store. It is an automatic process and only takes a few hours compared to up to two weeks in public store.
From the end users point of view, after it is installed there is no difference. It is the same app and it does not expire (as of today).
We are looking to develop an iPhone App communicating to webservices that is hosted internally at the customer site. Note that this is our first iPhone native App and using monotouch to do the job.
We will be maintaining the code and release updates periodically. However, the users needs to update only the version required based on thier local webservices and backend processes. For example, if the user is still using the version 1 webservice don't need to update the App at all, where as the users with version 2 needs to update to the matching App and so on.
We want to control the updating process or at least find a solution where if the user updates to the latest App, it won't come up with an error because the connected webservice is out of date.
We were thinking of the following processes, but nothing seems to be solving the issue.
1) Leave the app on the appstore but control the update processes somehow based on the webservices version. So when a user try to update, it will not update unless the required webservices is available. (Annoying part on this is users may be prompt that there is an update available even though those are irrelavent for them.)
2) Control the update outside the AppStore. Something similar to In-house development.
3) Stop the updating process entirely from the client, and only trigger the updates from the webservices end.
i.e Inform the client that it needs to update when the webservices updated, and the client will run the update process at that point.
However, it could be tricky, if the customer's updated to the webservices version that is not the latest.
1) There is no way to do what you want to do with Apple's AppStore, either an app can be updated or it can not, you can't add additional conditions that requires running code on the device itself.
2) That leaves in-house enterprise deployment - but this is restricted to deploying to your own company, you can't deploy to different clients this way.
3) You can't stop updates from your app, since you can't run code when an app is updated.
There is a 4), but it requires more work on your end:
4) Have your app support support older webservices, either through some sort of configuration the user can set or it query the web service for its version and selects accordingly. This has the additional advantage that an update can be deployed to all the devices first, and once all the devices have been updated, update the web service.
I would propose a fourth option: dont control/limit updating :)
Ship an app that uses a Wrapper object to access the service and that object internally handles different versions of the webservice.
apart from that.
1) doesnt work (if I get what you're doing: trying to influence the appstore updating)
2) sounds doable, and if you dont care for the appstore, it works
3) why? users love updates :) + there will be critical bugs
Is it possible to automatically force an update of all installations of an iPhone app without requiring interaction from the users?
According to this thread it is impossible to do so for apps deployed on Apple's public app store, but another more recent thread describes a way to at least inform users of updates, but still forces them to take action manually. With the Enterprise Program becoming available to most companies now (the requirement of 500+ employees has been dropped) can we hope to achieve it with the Enterprise Program?
The reason I'm asking is that automated push-updates of applications are a common demand and indispensable requirement by many businesses that use mobile devices. Blackberries have always won over iPhones in the past, because they had this feature while iPhones did not. Has the situation changed now?
Update: Apparently, there is another problem. Apple has a limit on the size of app downloads of 20MB over GSM which to my understanding also applies to deployment within the Enterprise Program. Unless all users consistently have access to a WiFi connection, this is another limitation that needs to be taken into consideration.
Update 2: I have submitted a feature request to Apple. Maybe it helps to expedite the improvements.
I don't believe you can force an update, though you can:
Remotely disable an existing app, if urgent, and
Design your app such that when it is outdated it alerts the user and provides a one-tap link to download a new version (technically two taps, one to load the web page with the app and one to install the new version).
It's not the ideal system you note would be so helpful, but it's an improvement over the earlier system where users had to sync with iTunes at a desktop/laptop in order to perform the upgrade.
I am seeing a lot companies popping up that are offering services that let you build apps using your own RSS feeds, photo feeds, etc. Some even say that you can instantly have the app run on your iPhone.
How are they doing this? Even if they somehow created a script that could automate the Apple Provisioning Process, aren't they limited to 100 device IDs, and don't their apps still need to be approved?
Are they not being transparent with their customers, or am I missing something big?
http://swebapps.com/
http://www.kanchoo.com/
http://www.appbreeder.com/
And there are a ton more out there
My guess is that they are controling the client on the appStore. You provide content with the constraint of their client.
Looking at swebapps, it looks like they are actually submitting a native app, on your behalf, to Apple. Remains the mystery on how they can update functionality without resubmitting to Apple.
All apps built through the SwebApps
platform rely upon media and data
stored on cloud servers. Hosting on
cloud servers allows our apps to be
updated in real time, without
re-submitting updates to Apple and
requiring users to download an update
A client has asked us to develop a proprietary in-house app for managing their back-end systems. However, we are a small development company and I'm certain that their company does not have >500 employees.
Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?
(just to clarify: obviously, we would like to go through the official enterprise program but seeing how the company doesn't have >500 employees, this isn't possible).
UPDATE (27/09): It appears Apple have removed the 500 employee limit for the enterprise distribution See here. So this will probably be our route now (which is helpful because the app is approaching completion). I'll update this as we go through the process if anyone would like me to, so that others may get an idea of what the actual process is like.
You can submit the app as a completely free app on the AppStore but require that the user log in and authenticate to use it. That way anyone can download it but you control who can actually use it. Apple does all the distribution for you for and you don't have to worry about Ad-Hoc deployments or IT departments.
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
When a user launches the free app they are asked for a username/password/whatever. That information is sent to the web-based configuration management system and confirmed. If the app receives an acceptable confirmation from the configuration management system it unlocks itself for use by that user.
The app can either re-authenticate every time it launches (useful if you want lots of control) or it can store a key file locally indicating that it has been authenticated. If it sees the local key file when the app launches it considers itself authenticated and never checks again.
Whether you use one user account per person or one for the whole company is up to you.
This style of distribution is very useful if you want to have control of who can use the app but want the ease of deployment that the AppStore provides.
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
If you keep track of device UDID on the configuration server you can also pre-load it to allow a certain set of devices to work.
Further, nothing I have described is iPhone specific so you can use the same configuration management system and concepts on other platforms like Android (or even desktops) if you ever port the app or build other apps needing this in the future.
Also, since the action of authenticating devices is not processor or data intensive you will likely never incur a cost if you build this on Google AppEngine as you will never go over the free quotas and you will gain the stability and scalability of Google's backend architecture.
As this particular deployment is for managing an in-house back-end system deploying it through the AppStore can seem insecure because there is proprietary information embedded in the app, in particular the information that allows it to connect to and authenticate against the back-end systems.
The solution to that is to not include this information within the app and simply have that information be part of the response that the app receives from the configuration management server. Basically the app contains the logic necessary to perform its function but without the connection information it has no ability to manage any back-end system.
If you make the app authenticate every time it launches you can change the connection information on the configuration server and the app will update to the new information without any new deployment being necessary. The user just needs to restart the app. This gives your client the flexibility to change their internal network configuration without invalidating your application code. You could also make this information manually configurable within the application but then you incur an IT cost when setting up the application on each device and if you already are going to set up a configuration management system you might as well use it.
To further secure the above solution you may want to have the configuration management system be in-house and behind the company's firewall so that regardless of who gets a hold of the app they cannot connect to the config system unless they are within the company's network.
I was researching this yesterday and today, and it appears that Apple has just (within the past week) removed the >500 employee requirement for enterprise development. However, I believe you will need to develop/deploy for a particular client using a development toolkit registered by the client.
So if you do work for client A and client B, both client A and B will need to sign up with Apple as business developers, at which point you can develop apps for them (as a contractor) and use their tools to build and deploy within their enterprises. I would think it would be a good idea for your company to also be registered as a business developer.
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
Jail-broken may sound scary, but it's actually pretty advanced, now-a-days, and can be managed quite easily. Still, it voids your warrantee (unless you're willing to restore-to-factory and be not-honest about it ;)
Still, technically, it's an available option and can be made to work, if you're willing to plan it out.
Let us know what you decide, and the pros & cons of that method.
Another obvious although not neccesarily pleasant is to submit your app to the app store as an app but can only be accessed with a client password. Assuming you can get past the aapp store process this might work for you.
Olie said:
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
But to be clear (correct me if I'm wrong):
if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.
So, Apple doesn't give us any choice, are you really big (>500 employes)?? ok so you can do what you want etc otherwise... "byebye"
Moreover, forget about what "Bryce" said before, an app like the one he described would be rejected with the "limeted audience" motivation.
iOS is not for enterprise app....if you don't want to rely on some clever hackers (i.e. jailbreak)
Ad-hoc distribution is limited to 100 devices per app, that's true, but you can add the project n times to the apple developer center, so you can deploy it to n * 100 devices
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
I would not jailbreak, I would not do ad-hoc because it is limited to 100, and I wouldn't make everyone put their phones in developer mode.
For future maintainability, enterprise mode is the way to go, so see if you can navigate your way through the process without mentioning that you might not be quite 500 users.
Also, I saw your comment about developing using MonoTouch. I would talk to Apple about this before you do anything else, because given their recent policy changes I am pretty sure this will get your app denied from the App Store and the Enterprise program.
Edit: I checked the Mono web page. It seems like Apple may still be letting mono apps in, and the Mono creators insist that it is kosher, but you might be running the risk of having your future app pulled from phones at any time.
A better edit: Straight from the mono website: Enterprise MonoTouch
It is important to point out that the new iPhone Developer Agreement terms are for AppStore deployment and not the Enterprise program that allows deployment of in-house application to users in the enterprise (using the Enterprise Deployment program).
So you might be good there as long as you can get into the enterprise program.
You can completely bypass the App-Store or Enterprise Developer Program approval process, if you develop your app as pure HTML5 solution.
This technology is called webapps. And they can be pretty advanced in functionality. You automatically have cross platform readiness and very easy deployment options (as webclip this can be distributed via .mobileconfig configuration files)
See http://www.apple.com/webapps/whatarewebapps.html
There is another solution: an own app store:
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
Or:
http://www.appcentral.com/
More info:
http://www.apple.com/iphone/business/integration/mdm/
http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002
In theory the proposed solution of publishing a free app meant for one company is not valid, since published apps in the app store should not be intended for a "limited audience" (whatever that means), according to:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?