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.
Related
Google and Facebook offer SDK for conversion tracking on iOS (from online ads to app installs):
Google: https://developers.google.com/app-conversion-tracking/
Facebook: https://developers.facebook.com/docs/ads-for-apps/mobile-app-ads
However, I could not find equivalent SDKs for the Mac App Store.
Are there equivalent SDKs for the Mac AppStore?
If not, what's the best way to measure conversion rate for installs from the Mac App Store?
The approach that most people use for this is to place a tracking pixel into their app.
On the first run of the app (note this is not the same as install as someone might install but never run the app), the tracking pixel fires and you can then just count the fires of that pixel.
Attribution (i.e. what caused that install) is difficult as usual - there are third parties who exist who can act as an intermediary that can do this, e.g. HasOffers or Kochava are two that spring to mind.
N.B. for Android installs from the Play Store, this "just works" with AdWords.
At present Apple doesn't provide conversion tracking. Later this year it will. It's unclear to me how you think an SDK would be involved; it won't be.
For anyone else researching this (there are surprisingly few results for this topic on Google) you should focus on tracking conversions with App Store by Apple. Make sure to use UTMs to see which campaigns are performing.
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.
I have developed five apps with name of five different football teams. Which shows event schedule of respective team. Apple rejected all of them and giving reason
"Developers "spamming" the App Store with many versions of similar apps will be removed from the iOS Developer Program"
Now, I have seen following Apps are almost same and available on AppStore
http://itunes.apple.com/pk/app/brookwood-medical-center/id434593012?mt=8
http://itunes.apple.com/pk/app/doctors-hospital-of-manteca/id430928072?mt=8
http://itunes.apple.com/pk/app/doctors-medical-center-modesto/id447790452?mt=8
Now what is developer spamming? Anybody can explain it?
It is not a technical question, but it is probably related to your code, so :
I think Apple rejects your applications for that reason when you use the same code base (or a close code base) for multiple applications, presented as different apps.
they must be thinking your are creating the same app under different names to gain more visibility in the store.
You should contact them and try to explain your case, or change your apps code and UI significantly enough to prove them these apps are different.
Create one football app and allow the user to buy teams as in app purchases.
Let the user have one team included in the price of the app.
Now, I have seen following Apps are almost same and available on AppStore
This is a common mistake. You can not use the existence of apps in the iOS App Store as any sort of precedent. These apps may have been accepted by accident, or under a previous interpretation of Apple's rules, which will not apply to your submissions.
Go by the current interpretation of the App store guidelines.
Maybe sell your apps to the respective teams so that you won't be submitting multiple apps, or running into any trademark licensing problems.
"Developer spamming" as explained by App Store Review Guidelines:
Developers "spamming" the App Store with many versions of similar apps
will be removed from the iOS Developer Program
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.
Apple doesn't offer promotional codes for in-app purchases. What's the best way to let users try the features or content unlocked by in-app purchases for free, while complying with Apple's Developer Guidelines?
The idea is to allow a special set of users (reviewers, key fans, etc.) to access the content or features offered as in-app purchases without paying.
Examples of apps that worked around this limitation would be much appreciated.
You could submit a version of your application that has all features unlocked by default.
Submitted apps have a publish date that you can set when you submit (and I believe you can change this on the fly as well) you could simply prevent the app from being published in the App store but still be able to give promotional codes for it.
Promo codes apply to a specific app version, so when users redeem promo codes for a version of an app that hasn’t been released yet, they download the prerelease version.
Source
Something like shareware? An app, that has a subset of features enabled until in-app purchase? Apple allows it now.
As example. We've a puzzle game, that has 12 difficulty levels. 4 or 5 of them are available for free and others are unlocked after in-app purchase.
I'm working on this now.
What I'm doing is I generate a random code/guid and store that on my webService's DB. Then give that code to who ever you want. They enter that code and it calls the web service passing the code, and device UDID. The webService returns another code indicating if that promocode was valid. If valid then the app will add that purchase to NSUserDefaults or Core Data (however you keep track of purchases).
If you don't have a server up and running (say the content is already in the app bundle) and you don't want a server would require you making an algorithm to generate keys that your app validates. However this is far less robust. Using a web service allows you to prevent 1 working key from being distributed between all users, as you can tie 1 promo code to 1 device.