Let's assume that I have got two applications:
A - which is old product hard to maintain, webview-based, no-ARC, iOS 5.0 and all things that you don't want in app
B - new, light version but less features
Both apps are free, and do not use any in app purchases, they gain money on ads.
From business reasons I cannot remove A app from the AppStore, and I know, that there are some users that will be using B version.
By the time version B will catch up with features of version A (let's call it B') and old app will no longer be needed with one exception - users. I would like to replace app A with B', is there any way to merge those two apps into one, so that B' version will be available for A and B users as a one app?
There is a similar question App Store - Best way to merge a paid and free version into a free version with IAP but as I understand solutions you need to force A app users do download B' and I want this process to be transparent for users.
At the point when you finish features for app B cannot you release it as app A to appstore?
You would have to maintain 2 versions of app but basically they would be the same, just 2 apps in app store.
Related
We're trying to decide between these two services for an upcoming beta. The new TestFlight looks much improved but we are still concerned about 3 things:
The user experience for testers (iTunes reviews of the TestFlight app imply this can be confusing)
The possibility of rejection or delay by apple when reviewing our beta releases.
Limited to IOS8
Hockey, on the other hand, seems to have a better tester UX. It supports multiple OS versions. And of course, no review is required.
The downside with Hockey seems to be a limit of 100 devices: http://support.hockeyapp.net/kb/client-integration-ios-mac-os-x/adding-new-devices-to-your-provisioning-profile
Here's our comparison grid: https://docs.google.com/spreadsheets/d/1CuYlsLsZPW-79hEre7jLppfwQpG4WmW3fDvHvIJ86wY/edit#gid=0
Would appreciate any feedback.
We've been beta testing our App via both HockeyApp and Apple's new Testflight within the last few weeks as well. I would recommend using both in parallel and seeing the pros and cons for yourself and from there you can choose one over the other. Here are our insights from the last few weeks:
HockeyApp Pros:
no need for an approval process
quick upload of new versions while maintaining access to old versions
HockeyApp Cons:
requires a bit more work to initially set up each beta tester (need
to have their device registered with HockeyApp so that you can
register their UDID with a provisioning profile and then a new
archived build needs to be uploaded to HockeyApp containing that
updated provisioning profile)
Only 100 tester slots (although unless you're really close to app store submission, you probably don't even need 100 spots)
TestFlight Pros:
Don't have to deal with UDID or provisioning profiles, strictly
emails only
1000 10000 slots
Now includes sharing of public links, so that other testers outside your organisation can use to download your beta builds.
Beta Approval process is pretty short (1.5 days for us)
TestFlight Cons:
Need iOS 8 to install TestFlight
Only 25 internal tester slots
Only can have one active build at a time Now supports having multiple active builds
Got a general question(s) for you on implementing a free and paid version of an app.
I have it setup now where I have 2 targets within the 1 app/project and I specify with the def syntax for what is in the lite vs paid version.
It works and runs both targets.
1) How do I have the user purchase the paid app directly from the free version? (Found multiple older articles saying linking is fine and others saying that will get rejected and must use in-app purchase)
Can I use a link tied to a tab bar item or button like this,
NSString *iTunesLink = #"http://itunes.apple.com/gb/app/wired-news-uk/id435728870?mt=8";
[[UIApplication sharedApplication]
openURL:[NSURL URLWithString:iTunesLink]];
OR do I need to implement the storekit for an In-App purchase?
2) I was going to put a new Tab Bar item at the bottom (to link to paid version) - haven't tried yet but I should be able to setup the tab bar one way for the free version and another way for the paid version, correct? Essentially, hiding the tab bar item to purchase the paid version once upgraded.
3) Submitting each app (free and paid) version to the app store - I'm assuming I will be able to set the target and archive the binary for upload for each, right? Two separate app submissions in itunesconnect?
I have several Lite/Paid app pairs in the app store (all were originally created before IAP existed). I've made many updates to these apps over the years so it seems Apple is fine with the idea in general, if you do it right.
1) You can't actually purchase the paid app from inside the free app. The best you can do is send the user to the store for your paid app.
2) That should work. In one of my apps, I have an extra icon in the main toolbar that brings the user to the app store page for the paid app.
3) Yes, you submit two completely separate apps. You setup two apps in iTunes Connect each with their own unique app id.
A single project with two targets is the easy and proper way to setup your code. For me, I do two archive builds, setup two apps or app updates in iTunes Connect, and submit the two apps/updates to iTunes Connect. I always keep both apps in perfect sync. Apple always seems to review them together and always pushes them out to the store at roughly the same time. Only once did the two get approved more than an hour or two apart.
The main thing you must be careful with is the free version. It can be "Free" or "Lite" but not "Demo". The free version must fully function. DO NOT have any UI elements in the free version that are disabled because they only work in the paid version. It will get rejected. If it doesn't work in the free version, make no mention of it at all in the free version.
Most of my app pairs, the free version allows for limited data compared to the paid version. When the user attempts to add data beyond this point, I popup an alert with a nice reminder that the free version a limit and offer them the chance to upgrade. Other than this, there is no other annoying popups offering the paid version. It's OK to have a button or whatever in the free app to let the user upgrade, just don't shove it their face or popup any sort of reminder after X uses or time. A free version of an app must fully function in its own right.
Here's my take on free/paid app pairs versus IAP:
Cons of IAP:
- No promo codes for IAP
- You can't make IAP free for some period of time (sale or whatever)
- Free apps tend to get lower ratings because any yahoo can download.
- Extra coding for IAP
Cons of free/paid pair:
- Two targets, two app releases, two sets of images, two sets of stuff in iTunes Connect
- Split downloads and ratings/reviews.
Personally, since I've been doing this for several years now, the extra effort of submitting two apps is trivial.
Edit:
One thing I forgot to mention - there is still no guarantee that Apple will accept the apps this way. But there are plenty of examples of such apps so it should be OK if done correctly.
If you want to have two apps, then you must have two technically independent submissions with different app id-s. It may be tricky to have it from the same project, not sure if you can do it using two targets. Technically AppStore rules do not allow "upselling" paid version from free one, but if it is not too aggressive, then maybe it will be approved. Safe solution would be to use InApp Purchase, this gives you many benefits:
quite is easy to implement
no need for two application codebases
you have single download count and item in appstore
Actually this solution with two separate apps made sense before in-app purchases, I do not see much point of that today.
I have already developed an app for iOS and I want to upload it to AppStore. I am about to buy an Apple developer licence for iOS so I would like to ask some questions to people that are already enrolled in a program like that.
First of all I am an individual programmer, I don't own a company, so I should get the individuals' license currently costing $99. When I submit an application as an individual to AppStore will it show my real name as the company or can I choose whatever name I want?
Secondly the name mentioned above will be the same for every application I upload using this licence?
Thirdly and most important. My application will not be free. However I would like to have a free edition too to show the basic functionality of the paid version. What's the difference between:
having one application that is free for starters and then you can upgrade and pay?
having 2 different applications where one would be called light version?
Is it harder for people to crack and put on installous the first option? Because many times I've seen on installous downloading an application but it was without the paid upgrade (maybe I am wrong here, though...)
You still select a company name which will appear on all your apps and is very difficult to change.
With regards to having a lite version, you may find apple would rather you use the in app purchase upgrade route and may reject one of your versions.
Regardless, the In App Purchase upgrade would be less "crackable" than a paid for full version. Especially if you verify receipts.
Am I being particular dense today? I'm working on an app that needs to offer legacy subscriptions to old iOS versions and auto-renewing subscriptions to newer iOS versions.
Normally I would check using a respondsToSelector test for something appropriate in the classes I want to use, but I can't see anything in the storekit that has changed that would allow me to do the test.
So how should I check to see if the device supports auto-renewing subs? I know I could check the explicit iOS version number, but I'd really prefer not to do that.
Is there a more sensible check I can do?
Why not just check for the iOS version that you need? How hard is that?
Hey Roger I was in a local meetup group for iOS developers and the topic of auto-renewing of subscriptions came up.
1 It is meant for "Magazines", which I would assume works only with Newsstand Apps
2 and it is ONLY meant for "Established" publications.
Which implies a printed version, and not just any ole' publication. This must be a nationally syndicated thing, something you would find on every major news stand in the country.
From what I gather in the conversation, Apple does not mean for the auto-renewal feature to open any new monetization channels for app developers (not yet at least), but rather the feature was created to extend the existing business model of print publications to the iPhone iPad digital media. Perhaps sometime in the future, this feature will be extended to all apps in the app store. Here's hoping.
I am developing an iPhone application which I need to distribute to an organization of about approximately 50 people, no. of users can increase or decrease in future.
I checked my iPhone developer account, there I got that I can distribute my application via Adhoc Distribution up to 100 iPhone or iPod touch users. So I think it should be best way to distribute my application to that XYZ organization.
On further searching I found that there is also an - iPhone Developer Enterprise Program, which is available to companies with 500 or more employees and a Dun & Bradstreet number.
So I want to know - which will be the best way for me according to my requirements ?
Also I want to know that say if I choose Adhoc distribution then is there any way for automatic up-gradation in it ie. to install new version of my application on user's iPhone or iPod without deleting the old version.
Thanks,
Miraaj
If you do not have something seriously wrong with your persistence frameworks, than you should be able to upgrade the app on devices, while retaining the data just by providing the users with a new version of the .ipa file.
Ad-hoc seems to match your needs best, but remember, that you will have to get the UUID of all 50 iPhones the app will be installed on. A bit tedious and time-consuming. Enterprise would be better in that respect, but you might not be able to qualify for it. It's also extra expensive.
I am not surer what you mean by deleting the old one. If you want to have multiple versions of the app available on a device, they will not be automatically updatable and data sharing will be very complicated. Ad-hoc might be about your best option.