I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).
Related
I need to create and App that will run in the background and will monitor the user's behavior in term of applications installed, opened and deleted.
i.e Application will save the information in the database that at what time user has installed/opened/deleted an application in iphone.
I wonder if its possible and Apple will allow this??
I tried to google on it but did not get anything, i know if its possible then it would be possible by multiasking only??
Can any one please help me on the same.
Brn
Not possible. Your app can only run when the user chooses to (except for a limited sub-set of tasks like VoIP, etc).
Your app can know nothing about other apps.
iOS apps are sandboxed. I wouldn't say impossible but certainly not allowed. You'd have to find a security hole to give you root access first. Oh, and notify us when you do ;).
Edit:
Maybe it wasn't clear in my post but I was at least half joking. Not sure why you want to do what you want to do. I can imagine the following scenarios:
1) Your company wants to monitor everything their users do on their phones. In that case I would either
a) lock them down and only allow app installation through a company portal (enterprise distribution is possible in iOS) OR
b) forget about iOS alltogether. Blackberry would probably be closer to what you want, although I don't really have experience with that platform. Also, its future is not sure.
2) You're trying to do something illegitimate. Because of iOS's locked down nature it won't be easy. See how few successful attacks there have been in the last years - and that's for a highly successful platform where an attack could be high paying both in terms of money and reputation.
I am building an app for a client that will have 30 days of content for free, thereafter you are required to buy a subscription via in app store purchases.
However, I have read that you will get rejected if you have trials.
Don’t set time limits on any of the functionality of your app, either
for run times or life times. Applications that only run for a set
number of minutes per session, or that expire altogether after some
period of time, don’t recruit customers so much as leave a bad taste
in their mouths.
Finally, they also say "your app will be returned to you by the App Review Team for modification if it is found to have time limits".
This seems odd because I know the Guardian and all major newspaper apps have limited functionality.
The Guardian app is free but you get limited functionality?
The Daily app is free, but you have to pay for daily subscriptions
and has limited functionality for the period of your subscription.
The Times app is free, but is a free trial (of sorts) (plenty of
complaints about it)
There are other examples which seem to differ from Apple's policies.
Lets say you have an app that is free, but then you have to pay for subscriptions to gain access; however according to the rules this is considered limited functionality -- yet there are lots of newspaper apps that do exactly that.
I'm confused.
Can someone clarify the situation? Can apps have trials?
Thanks
It is difficult to clarify the situation because unfortunately the guidelines are not necessarily set in stone. They can and do vary on an app and publisher basis.
In the case of The Times and The Daily, both apps are produced by News Corp. It is perhaps safe to say that News Corp has a good deal more influence with Apple than a one-man development shop producing an iPhone game. Apple would be loath to admit it, but there are clear cases of popular apps on the store that don't conform to the guidelines, where they have tacitly made an exception.
So what I would say to you is this: be sensible. Don't have an app that quits automatically when your trial runs out. Think about what would be acceptable to users. It's very much a case of nothing ventured, nothing gained. Take a risk, submit your app with your limited trial, and see what happens.
With the Guardian app, we had to deliver an app where you always got at least some fresh content if you were using the free version. Subscribing opens up more content to the user.
I think, you are mixing up "content" and "functionality".
You can deliver content items (i.e. an magazine issue) for free or user has to pay for it — so the first n issues, or all issues in a certain timeframe, can be free, while the others need to be paid. But if an user purchased an content item before, you have to re-deliver it for free.
You can sell functionalities (i.e a search in the magazine's archive) as-well. But you cannot give it to the user for free for a certain time and them make him pay.
So the general rule is: What ever the user got from you — you cannot take it back from them and make them purchase it again.
There are plenty of free apps which provide limited functionality. They don't provide time limits though (or at least they shouldn't). I'm guessing it won't be as clear cut as accept or reject for Apple, because I did encounter an app which closes itself after 10 minutes, opening a web page to purchase it (closing an app is also against the Apple Human Interface Guidelines, as an app should never terminate itself).
The guidelines mention this is only allowed for specific types of content:
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
I am a member of a gliding club with 150 members, and we want to have our own iPhone app. Requiring a member login, the app would be usable only by members of the club, and it would be used by an estimated 20-30 people.
Is it even possible to disribute such an app to non-jailbroken iPhones? According to my research:
It wouldn't be accepted on the App Store due to "limited audience".
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
Ad hoc distribution would be fine for us except for the expiration time associated with apps distributed in the manner.
Are we at a dead end?
Thanks.
Edit: In case anyone is wondering why I didn't just ask Apple directly: I did, and their answer was, "We are unable to advise you with respect to the Apple Developer Program that best fits your needs."
I'm not 100% on your question.
But depending on your requirement, pretty much everything you need can be achieved as a web app, with the correct coding behind it i.e. CACHE MANIFEST you could make the app function similar to the a native app, available offline and can be saved to any iOS device through the browser.
Give me a shout if you need more information.
Hope it helps
Gary
You could always try to make the app a little more "global"? Perhaps offer some free stuff for Joe Bloggs to use, but tucked away you have your real motive... that way you can get it released legitimately.
I've seen some real disasters in the app store that shouldn't have made it, and I'm sure Apples screening isn't as intense as we might think. (example: that flash light application, when pressing a sequence of buttons it would enable free tethering).
Best of luck!
Yup. You seem to have all the options laid out pretty clearly, and there's no other way to do it. Except developing for android, and just distributing the application freely and without arbitrary restrictions.
Sorry.
Ad-hoc distribution would give you about 90 days expiration time, i think, whereas enterprise would give you a year. Though gaining enterprise status in the eyes of apple is easier said than done.
Even if we were able and willing to pay $300 for the enterprise distribution model, Apple would likely not accept us as a company.
You don't have to be a company to apply for the enterprise account, you just need to be an organisation with a DUNS number.
I am a complete novice and have no technical skills and little knowledge concerning iphone app development an in-app / itunes store purchases.
But I have been playing with some ideas for my coffeeshop / lunchbar and was wondering If any experts would like to give me some feedback on my ideas.
As I said I run a coffee and lunch(break) shop and allot of my customers are iphone (and blackberry) users. What also happens alot is that the customers ring to order their coffee and food so that they don't have to wait (and waist their precious lunch time).
I myself am an Iphone user and really like the way it works (most of the time).
So I was wondering I is possible or will it be possible to develop an iphone app for my customers and have them pay for the order "in-app". I get a bill of the order in my mailbox and they just chout their name and thats it !?
Might sound a bit low tech but if apple have someones creditcard details and a mobile ordering display then they could function as a cash register of bank ?
thanks,
Jonathan
You can't do this according to Apple's terms of use:
You must deliver your digital good or service within your app.
Do not use In App Purchase to sell real-world goods and services.
Even if allowed, you'd lose 30% of your revenue to Apple using in-app purchase.
There are point-of-sale apps for iPhone that allow you to swipe credit cards. One of the Twitter founders has a startup called Square that'll be doing this. If you wanted it to be an app that users could install themselves, though, you'd likely be best off doing a custom one and hitting a payment gateway in the backend (Chipotle's app is a good example of this).
The original asker is just asking if this is possible, which it is! If you don't take the term 'in-app purchasing' literally. Just use paypal or some other payment method through the app. Ebay does this and so can you.
As long as you aren't selling something that competes directly with Apple (like Sony's digital book store that got shut down) you should be fine using a payment method other than the built-in functionality called 'in app purchasing'.
You have a good idea on your hands and it should be possible to find a way to take customer's money through the app.
Though you could probably use In-App purchasing for this, you would have some interesting work to do to make it work smoothly. You would probably be better off developing your own shopping cart application that lets your customers order "online" and write a custom iPhone application for them - skipping Apple for the purchase of coffee and donuts...
-t
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase