Related
My company currently has two applications in the app store: a full, paid version that includes two ebooks, and a "lite" version that does not include both books. We've just developed a new version of the app that instead implements the two books as IAPs, with the intention of merging the two apps into one. I'm at the point where I'd like to submit the app, and I'm not sure of the best way to proceed.
Current plan:
Update free app to the new version with the IAP books.
Rename the free version, removing the "Lite".
Delete the existing paid version from the app store.
Potential problems with this plan:
Those who've already paid for the existing full version might feel ripped off, since their version won't be receiving any of the other updates in this new version.
There will be a name conflict, since we want the new app to take the name of the old paid one (removing the typical "- Lite" signifier). This won't be much of an issue in the App Store if we immediately remove the paid version from the store, but can make for a confusing user experience if a user downloads the new version alongside the old paid version.
Along the same lines, if we delete the old paid version as soon as we upload the new free version (with the same name as the old paid version), it's easy to imagine some confused users of the old paid version deleting their existing paid version and downloading the new free version, only to realize they'd lost the books they'd already paid for, with no way of re-downloading the old paid version.
My questions:
From a real high level, are we handling this the wrong way? I've Googled and Googled, but I haven't been able to find much guidance on how to combine paid and free version of apps into one.
Is there any way for me to determine who's already purchased the paid version, and "gift" them the book IAPs in the new free version? If we thought this threw sooner we could've logged the unique IDs of all of those paid versions, but I do believe that's against the rules now anyway, correct?
What other sorts of issues might arise by giving the "- Lite" version the same name as the old full version?
Thanks in advance for any and all assistance or feedback.
We just did that with our FileApp Pro and the free FileApp. We got rid of FileApp Pro and now the new FileApp has In-App Purchases. However we wanted to have all users that bought FileApp Pro to have all In-App purchases of FileApp for free.
Here is the method we used:
We are sharing flags between FileApp and FileApp Pro using the iOS’ “Keychain sharing entitlement” which allows two apps to share the same keychain data. This allows FileApp to know that FileApp Pro is installed. Then we wanted to make sure that FileApp Pro privileges remain available in FileApp through the iTunes account of the user so we used a free In-App purchase to do that. The FileApp Pro user when launching FileApp for the first time is asked to purchase a free In-App purchase so all his privileges remains across devices even if he reinstall FileApp.
You will find a complete article on our bog describing the method:
http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
Edit: Here's the archive link to the above post that doesn't seem to be available now: https://web.archive.org/web/20160309135133/http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
I would think it might be best to turn the paid version to the free so at least your original paid customers are taken care of the most. Depending on your user base you could even ensure the original paid users aren't shown any ads or other restrictions by doing an intermediate release to have those users save something to user defaults. Then you could provide an update to the free version with a UIAlertView that asks them if they want the full version for free and direct them to the app store to download it. I assume you have many more free users but you would probably upset less people with this path.
I know two apps that did something very similar. The Economist, and USAToday app, which literally alerted the user to ditch the current app and download the new one. (Not sure why they had to do it that way though). So I am quite sure you are not the first one thinking of doing this.
If there is an option for you to provide account+sync capabilities, that'd be the best way to merge both the apps. One of my favorite apps, Gas Cubby, handled this pretty well. Gas Cubby has a free and a paid version. If you want to upgrade your from free Gas Cubby to paid one, you download a different app, and then sync data.
For your worries about how to restore content for the paid customers in your Lite app, you can use a URL scheme in the Lite app, which, when called by the current paid app, will enable those books for free.
As #rooster117 says, its best to turn the paid version free, and ask the lite version people to move to the paid-turned-free version. Of course put hard stop date in the app that you'll discontinue, so that all those who use it will move to the one app of your interest.
Your Problems:
This is going to happen regardless, you can't make everyone happy
I would go with removing the Free version of the App although, but before you do send a push notification to all the "Lite" version holds saying support for this app will be discontinued and direct them to the paid version
To continue on from #2 if possible, before discontinuing the "Lite" version if you have an account system setup to a server of yours release an update for both versions that syncs all of their books with your own server (not iCloud). This way when they download the new version (after the Lite is discontinued), the app will automatically sync the books back to the device.
Your questions:
As you relise there is no real way to merge two apps, from what I've seen from games to utilities is to remove the "lite" version as some point all together and if the user wants future content updates then they have to download the app still on the App store.
Refer to my Answer to Problem #3
I believe it will be out right rejected by the App Store review process, primarily due to the fact that they both perform the same function, i would suggest to remove the free one altogether
I have made multiple simple but fun apps for iPhone in the past few months and have had them rejected by Apple during the approval process.
I have put many weeks or months of effort in some cases. I just hate to have these apps go to waste without anyone downloading them.
Since those apps of mine are never going to see the light of the day on the App Store, is there a way I can let family and friends download those apps if I host those binaries on my website? Can anyone tell me the process or walk through instructions?
Are they simple enough that if I post them on Facebook most average users are going to get it? Is there already a website out there that lets users like me (with unapproved apps) to host those files for everyone in the world to download them?
Have a look to testflight.
You just need an email that can be accessed on the iPhone and add the specific user to test flight, once he is register you can get the iPhone id and add it to the provisioning profile.
When you create the build and upload it , the users are notified by email and the app is installed remotely by a few clicks.
You can authorize a limited number of users to test your app through ad hoc provisioning. The free service provided by http://www.testflightapp.com makes the over-the-air distribution and provisioning process fairly simple.
You might find these links useful
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
https://testflightapp.com/
Good luck
Harv
Why not just open-source them? You’re probably not going to make a lot of money distributing them with TestFlight or even Cydia. Instead, clean the code up to remove any proprietary things you don’t want to include (API keys, etc.) and put it on GitHub. Not only will this help the community, but you can use your GitHub account as a kind of résumé for future employers or clients. What’s more, you might even get free help with your code if someone forks your game and makes changes!
Old thread but could Enterprise developer's license help here, as long as you are not selling them apps?
Just a thought.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I work for a company that would like to create an app that we can distribute to our customers. We manufacture industrial equipment and we would like to provide an iPhone/iPad app to our customers that can interact with their equipment.
The problem is that we would prefer that the app not be downloaded from the App Store. We would like for this application to be available for our customers free-of-charge and would also like for them to have the ability to download and install the application on as many devices as they desire. However, we do not want non-customers (ahem, competitors) to be able to download and use our application.
What options are available? We have considered allowing the app to be available through the app store but in that case the app would be locked until the user entered an application key. This would keep the app free to download and it would give us the ability to control who could use our software. I'm not sure, however, if that is allowable by the Apple TOS.
The Enterprise license sounds like a potential option. If it is, what are the specific steps necessary for installing an iOS app on an Apple device if not through the App Store? I'm also not sure if it would break the TOS to distribute our app for this purpose under the Enterprise license. Is that the case?
What options do I have? Please realize, I don't own a Mac and I've never even attempted to write or distribute an iOS application-- I'm 100% new to all of this. Thanks for you help.
EDIT
Thank you all for the wonderful responses that I have so far received. Half of the questions that I have stem from the fact that I can't find the actual TOS agreement that I would have to sign if I became a standard or enterprise developer. (Yes, I've googled it.) Does anyone have a link to such documents?
If you want to distribute your app outside the App Store, you need to get an iOS Developer Entreprise license ($299/year). You're going to need a Dun & Bradstreet (D-U-N-S) number to enroll and can only deploy to 500 (registered) devices.
Edit: Another option would be to demand the user some authentication (such as user/pass) to use the app (think Facebook or Twitter). You could provide your clients with the credentials to ensure only a certain users have access to the app.
I think #ibeitia's answer is the best one, but here's an additional option: put the app on the app store, but make it all-but-useless without a login to your server.
For example, the Google+ app is useless unless you have a Google account.
You'd have to give a login to Apple so they can vet it, and of course I can't guarantee they'll allow it, but it's an option I'd consider.
(If you do go down that route, send an email to Apple's approval team asking for clarification before you start development!)
I work for a company that would like to create an app that we can
distribute to our customers.
From http://developer.apple.com/support/ios/enterprise.html (bold is mine)
I am a developer who wants to create an in house app for my client.
Can I join the iOS Developer Enterprise Program to do that?
The iOS Developer Enterprise Program should be used to develop and
distribute proprietary in-house applications to your own employees
within your own company. As such, your company would not qualify for
direct Program enrollment in this situation. We would suggest that
your client apply for enrollment in the Program, and, once enrolled in
the Program, your client may add the appropriate developers from your
company to their iOS Development Team.
The Enterprise Developer program doesn't allow you to sell your app to your customers. It's the customer, not you, who should enroll in the program.
I think your best bet will be to use Apple's B 2 B program:
http://www.apple.com/business/vpp/
This will allow you to have apps in Apple's business app store (not the ordinary app store), and control who gets the apps. You'd provide the redemption codes to your customers.
btw, I can confirm that providing an app with a login to make it useful would be okay with Apple - I've done it before.
Well your options are really limited.
You could go with the enterprise license but this is still limited to 500 device which still need to be register with the some how. (never had to work with the enterprise license).
But could you not make your app available in the appstore foor free but only make it work with you equipment. Thus make the app search for the equipment (via bonjour of wifi) and only work when it finds the device. This will make getting the accepted a bit harder but will work. There are some IP camera manager that work that way.
If your competitors really want your app they will get it one way or an other.
Just be sure you release an app before the competitors, do that way your company has the advantage.
Can someone provide concrete info on how the app upgrade process works on iOS as far as the developer is concerned? I've been rummaging through Stackoverflow only to find hand-waving explanations and no links to official documentation. Google search results only led to Cisco's IOS and the end-user upgrade process. I'd like to know the following:
How does the App Store know when you've provided a new version? Do I have to implement something in my app, which the App Store pings? Or do I set things up stuff through the Apple Developer website? I've been waiting 2 months for developer approval and have no idea what's going on behind those doors because I get access-denied messages when trying to read official articles.
Is there any Objective-C code I need to write for an upgrade to be possible? Any plist I need to edit?
How is payment affected when version 1 of the app is free, then version 2 is paid or version 1 is paid and version 2 changes its price.
Does Apple allow me to do forced upgrades? All the answers on Stackoverflow have been, "I think this is bad business logic" or "I think Apple forbids this, but I don't have the official documentation to prove it." At a certain point, very old versions will be too time consuming to support. You don't see Microsoft still supporting Windows 95, do you?
You just submit the new version to Apple. When it's approved, it will appear in the App Store.
Same as above, Apple pretty much does it all for you.
If you transition from free to paid, everyone that has downloaded the app for free will not have to pay to upgrade to the paid version.
IIRC you cannot force users to upgrade, but you can display a notification within the app to alert users that an update is available. To implement this, I would just have the app request a file on your server that tells the app what the current version number is. You do not need to support users on old version, if they have problems with an old version, it's fine to tell them to upgrade.
We have an industrial app that currently runs on a very expensive ruggedized PDA.
Since most of the engineers we sell to have iPhones we are considering moving to the much nicer newer platform.
A couple of questions:
Is it possible to sell iPhone apps with out the app store? Apple taking a 40% cut of a 99c iFart app is one thing but this is a $3000 engineering calculation app. We have also heard of the hassles some people have had getting apps approved.
Can we sell an iPod touch (I understand selling an iPhone without a contract is trickier) with pre-packaged software.
ps. Sorry for the anonymous posting, the company is a little nervous about our relationship with the PDA maker.
There are basically three different official iPhone application distribution methods that I am aware of:
- App store
With this method anyone with an iPhone can have access to the application. You can distribute an unlimited number of applications like this. Apple gets a 30% cut. Of course Apple must approve your applicaion.
- Ad hoc
You can distribute applications using ad hoc without going through the app store, but you are limited to a maximum of 100 devices. With this method you can distribute you application from a web site, email, etc.
- Enterprise
The method is for internal distribution in companies with more than 500 employees. Apple does not provide any more public detail that I could find on this method.
It doesn't sound like any of these methods meet your criteria unless you have fewer than 100 customers and don't plan to exceed that number. It sounds like from the question your customers are not internal to your company.
I would advise contacting Apple. They might be able to work out some kind of custom distribution deal.
Enterprise developer program allows in house distribution, avoiding the appstore. It's $299 vs $99 and doesn't include AppStore distribution.
For companies with 500 or more employees who are creating proprietary in-house applications for iPhone and iPod touch.
Apple also has a B2B Program, which sound like you are aiming for. It allows you to sell your apps directly to other businesses. You can find out more here: https://developer.apple.com/programs/volume/b2b/
Spotify has a free app you can download, but to use it you have to have a Premium account. So you don't have to sell your app for $3000 to go thru the app store.
You can give the app for free in Appstore, but it will require an online activation. The online activation will cost 3000$. If apple would not accept the app, you can try to create a very limited version (without activation) and get it accepted in appstore. Then release un update for it, which will enable online activation system.
It's a pity - the iPhone/iPod touch could make a really nice platform for automation/interface stuff.
I was working on an embedded industrial platform recently - a 16bit micro, 64K memory, a serial port and a 120x128 2 grey level screen for $1000/unit and $10,000 for the appalling OS/devkit.
I can't see how apple could possibly care if you purchase iPod touches, jailbroke them, installed your app and sold them to customers.
For a $3k app, the $220 for an iPod Touch is less than 10% of the sales price.
Testflight. Google it. Basically you get an account with testflight. Put your app on testflight. You send your customer an email and they click it on their iphone. It sends testflight an email with your customers device ID. Testflight sends you an email saying "a New customer requested your app" and their device ID. You add their device ID to your provisioning chain and rebuild your App. Upload it to testflight, they get a notification that it's ready, and they can install it. Somewhere in there be sure to get your money :)
Native app, no. However, you can create it as a Web App that's specialized for the iPhone, in which case you circumvent the app store altogether.
You could consider a HTML5 app on Safari which offers many of the features of an app like offline access, local storage, canvas for rich graphics etc. No distribution issues and no commission. Depends what you need - access to camera, compass I think is not possible. (Also: works on Android)
Edit:
Here's a great intro -
http://sixrevisions.com/web-development/html5-iphone-app/
How to Make an HTML5 iPhone App
Build a version of Tetris that is "for the most part, it’s going to be a pitch-perfect imitation"
Full Screen
Offline Cache
Persistent storage
If your app is pretty expensive, you probably have few customers and they receive personal support, so what you could do is the following:
Have each customer get their own Apple developer license ($99/year). Your support can talk them through the process, or you can probably do it for them. Give them a discount/credit for the $99 they pay to Apple.
Compile your apps logic into a library, and make a thin shell that loads code from the library.
Give the customer the XCode project for this shell, and the binaries for your code :-). Write a little OS X app that triggers the download of XCode, the compilation, and installation, so they can "compile" and deploy "the app they are developing" (a.k.a. your app) to their devices. Or, do it as a service for them.
Don't forget to get your lawyers involved. I'm sure there are ways to look at it in which this is legal, and interpretations in which this violates some license. There is probably a way to make this waterproof, e.g. by calling your customers "developers" and yourself "consultants" in the contract or something. Helping a customer compile their app is not prohibited :-)
If you do this, deployment is not going to be so smooth as if you go the official way, but you'll save a lot of money. For a $3000 app, instead of 30% you'll give Apple 3.33%. I haven't done this, and I don't know anybody who has, and can't even recommend it, but I also can't see why it wouldn't work. So it might be worth a try.
I wish. Short answer, no.
There is some kind of a hack, whereby you isntall your app in a ad hoc manner, but you can only have 100 devices. Painful road if you ask me.
The way to do this would be to give the app for free in iOs store.
But charge $3000 for an activation code or subscription fee purchased from your website.
You will need to give the free app some basic functionality of some kind, however. Apple won't approve the app if it doesn't do anything without the activation code.
If it was me I would do one of the follow:
1) Submit it to Apple and sell it for free. They then enter a license code bought from you to access the full feature set. Include a welcome page, about us, contact page for unlicensed functionality. As Apple won't approve it if it does nothing.
2) Get the companies you're selling to to open an Enterprise account with Apple. Then you build the IPA and sign it using their credentials and send them the IPA.
Good luck.
This article summarizes all the answers to this question and discusses Apple's B2B, iOS developer enterprise program, adhoc distribution and testflight.
http://mobiledan.net/2012/03/02/5-options-for-distributing-ios-apps-to-a-limited-audience-legally/
All of the solutions (except the test-oriented solutions, which are limited), however, force you to get Apple's approval before publishing and updating. This process can take time and can leave your users stranded when you have a critical bug that needs a quick update.
If this is a deal breaker for you, you might want to try developing the app for Android, which also has advantages and drawbacks, but in your specific case, gives you more flexibility.
In Android, you can email an APK file, a user clicks it, and the app gets installed on the device.
In iOS, every devices that is not a member of the "enterprise program", "b2b" program or is provisioned for testing, cannot install the app.
You have to jailbreak the iPhone to put an app on it not from the app store.