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
Would that be a reason for rejection of our app, if we use the word 'iPhone' or 'iPad' in our app name?
For example, names like - 'My iPhone Style' or 'New iPad style'.
I am going to submit an App soon and little confused about this problem. The thing is, It is necessary to use the word iPhone in my app name to get identified the purpose of my app.
Please help me. Thanx in advance. :-)
Your app will be rejected for two reasons:
You do not have the right to use Apple's trademark. It's the same reason you can't call your app "Mickey Mouse Clock" or "Microsoft AwesomeNote" or whatever. Review section 8 of the App Store Review Guidelines on the use of third-party trademarks, then the Apple Trademark List to see what trademarks they hold. iPhone and iPad are most certainly included.
You cannot use their trademarks in your product name, and you cannot use any of their trademarked names in a way that could imply the product had Apple's approval or was from Apple. See the Guidelines for Using Apple Trademarks and Copyrights, specifically items 1 and 5 in the Unauthorized Use of Apple Trademarks section.
looking on the app store I see plenty of examples of X App for iPhone and x App for iPad, however all of these names, unlike My iPhone Style, make more or less clear what the app does and use "for iPhone" or something to distinguish between versions.
I'm going to develop an iPhone app, and want to make sure what I want to do is possible, and will be approved by Apple.
I'm going to create an app that will be fully branded on per submission basis. I want to have one app per customer (our customers are companies) with their logo, skin, etc.
This apps will be downloaded and installed by the employees of each one of our customers.
In other words, we would use the same base code (logic doesn't change), but will brand it for each customer. Something similar to what Magento (http://www.magentocommerce.com/product/mobile) does, they created an Ecommerce mobile app, and they brand it to their customer, but the app logic remains the same.
Would Apple consider this as duplicate apps? what is the best way to do it?
Thanks in advance.
I would have said "no problem" until I read:
This apps will be downloaded and
installed by the employees of each one
of our customers
It sounds like what your creating is (a set of) private applications, which are intended to be targeted only to specific users - i.e. employees of the company.
Apple has a separate "enterprise" development program geared towards this - allowing developers to deploy programs for their own company - and do it outside of the App Store.
If your program is very specific towards the companies, Apple may make you do this - rather than putting the Apps up for general consumption on the App store.
See here for more details:
http://developer.apple.com/programs/ios/enterprise/
Also:
If your application is really intended for a wider audience, and your could in-fact sell/distribute it a such - you could "skin" the app dynamically. For example, on first-time launch, when you "register" with some "service" - based upon your email address it could download the appropriate skinning graphics.
I can say I know of several companies built on this strategy. The code doesn't change one iota from app to app, only images and names change and they continue to bring in revenue.
EDIT: Note this is against apple policy and if they find out they have been known to ban accounts. They consider it spamming and prefer that you sell one app that provides in app purchases. Directly from their feedback on a particular group of app submissions:
Thank you for submitting your
Photography apps to the App Store.
We've completed the review of your
apps, however, we are unable to post
them to the App Store because they
provide the same feature set and
simply vary the content. Apps that
replicate functionality with different
content create clutter in the App
Store, hindering users' ability to
find apps, and do not comply with the
App Store Review Guidelines
https://developer.apple.com/appstore/resources/approval/guidelines.html:
2.20 Developers 'spamming' the App Store with many versions of
similar apps will be removed from the
iOS Developer Program
You can now use Apple's Volume Purchase Program to release differently branded versions of the same app to different customers. The app can be free or paid. Each customer must have a DUNS number (Dun & Bradstreet). See the FAQ for details.
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.
I have an app that I was going to release as a free (lite) version with some of the total functionality and a paid full version with advanced functionality. Now, with in app purchase for free apps I am thinking of going that route with the ability to unlock features as needed. I'm not talking about a trial version that expires.I want people to be able to try out the app and get an idea of the interface and functionality before deciding to purchase the full functionality of each major section of the app, basically.
Here's an analogy of what my app would be like. Let's say you have a cooking app that teaches you to cook in different styles. There could be major section for French, Italian, and Chinese. Each section could have some rudiments unlocked in the free app so users can see the UI and basics of the functionality. Then, the user could decide to purchase each major section (or not) individually with in app purchase or buy the full versioned app (with the free/paid model).
One concern I have with offering a free app with in app purchase would be with feedback. I would be very clear in my description in the app store that there is in app purchase for full features but I'm worried that less serious users could/would leave negative feedback. I suppose that's always a risk but curious about any experience with this.
It also seems that it could be a whole lot more complicated keeping track of what portions of the app are locked and unlocked with in app purchase. I know I'd have to have all the code for the full functionality and "lock" the portions that haven't been purchased. How do people usually lock portions of their code? I'm not talking about the process of purchasing (I've read the In App Purchase Programming Guide) but after the purchase has been made. Would I just keep track of what the user has purchased and put conditionals on the sections that are initially locked? Or is there another way to do this as well?
My instinct is for the in app purchase (particularly since users could purchase the major sections that they want individually).
I would highly recommend using the in-app purchasing over having different versions available.
If you have different versions, users need to re-download the whole thing if they want to upgrade. This means they need to have twice the storage space and use up twice the network bandwidth to upgrade.
I don't think your review concerns are founded. If your application is well made and users like it, you'll get positive reviews. To avoid having users be confused, make sure the application clearly states what can be purchased. Also, some people just dislike everything and will give you one star. These users are unavoidable, but if your app is good, there should be enough good reviews to balance them out.
You're correct in your assumption that you would have to have conditionals for locked/unlocked content. However, this shouldn't be an enormous issue. Just persist what the user's purchased in a plist (suggested by Apple) or other persistent storage and make a class that you can query to find out if a particular feature has been purchased.
I suppose it makes sense to have lite app (with unlockable content via IAP) and full paid app. I'm saying this basing on own experience of selling apps on the AppStore. If interested you may want to look at my post in our company blog about IAP vs paid app.
http://bees4honey.com/blog/marketing/in-app-purchase-vs-paid-app/
In two words - having lite version with IAP and paid version will increase a total revenue in comparison with having only lite with IAP or lite+paid.