Loading...
Answers
MenuNeed help with cross-platform in-app purchases.
Answers
Typically Apple and Google will consider coins and credits a type of digital currency. Under their terms and services these types of products in an application must be transacted through the AppStore and Play Store so they get the 30% cut.
When I worked for Groupon, building their Android application, they were not required to use the IAP from either platform. This is because they were selling a product or service. As you stated - you're selling a service. You may need to change the wording from "Credits" to "Balance" (or something similar to that) and have that reflected as actual dollar amounts in the app. I would also be very clear that you are selling a service - not digital goods. If this is truly what you are doing (selling a service), then you should be in the clear.
Disclaimer: These TOS change all the time. The last time I dove in and read one end to end regarding IAP was about nine months ago. But I'm fairly certain the service and product thing still applies. You may want to consult your lawyer and review the TOS with them to be sure you're not in the grey area.
Succinctly, Apple is absolutely horrible to deal with for making apps, and they really do not like 'workarounds' and will ban your app if they get a hint of one.
That being said, here is a way you could potentially make it work out:
1) In your iOS app, charge more than in your android app, to cover the 30% take by Apple.
The creates another problem: it's too expensive.
2) To work around that problem use this: http://playseeds.com/
It's a new in-app-purchases model that cycles the payment money into microloans for people in developing countries, then you get the payback. I think you get the payment right away as if it's a normal payment (i.e. all the loan, and payback etc. happens in the background without you being affected). That payment model greatly increases user willingness to make a initial and repeated purchase.
Best of luck
Lee
Download Panda Helper
The use case I am describing is when a user’s purchased inventory is tied to an organizational user account and is tracked by an external service. For example, when a user buys a song from your mobile app on iOS or Android device, and then logs in to a web version of your app, the song should be instantly available to play in his/her collection. One of the in-app purchase types that is not compatible with cross-platform payments is the App Store’s non-consumable type. If your app sells non-consumable, auto-renewable subscription, or non-renewing subscription products, you must provide users with the ability to restore them. If you want to sell a cross-platform product that can only be purchased once, after reading the Apple definition, you may think that non-consumable type is the answer, but the additional requirement may confuse you. There is also one place where documentation mentions multi-platform services, but it does not say anything about non-consumable types. One of the features of App Store’s Store Kit is the ability to manage inventory of purchased items, meaning it will be responsible for filtering out items that were already purchased. This is handy if a user has lost or bought a new iOS device because it offers the ability to restore purchased items. However, when you let Apple manage your inventory, the purchased inventory will be tied to a user’s iTunes account and not your cross-platform user account. As soon as a user makes a purchase you top up his/her organizational account with content and consume the item. This inventory service is also used to filter out items that were already purchased because Apple is not a system of record anymore. Making all you are in-app purchase products consumables, even for items that can only be consumed once, might make you nervous, especially if you have not gone through the apple approval process before.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath
Related Questions
-
What is a better title for a startup head....Founder or CEO? Are there any pros/cons to certain titles?
The previous answers given here are great, but I've copied a trick from legendary investor Monish Pabrai that I've used in previous startups that seems to work wonders -- especially if your company does direct B2B sales. Many Founders/ CEOs are hung up on having the Founder/ CEO/ President title. As others have mentioned, those titles have become somewhat devalued in today's world -- especially if you are in a sales meeting with a large organization. Many purchasing agents at large organizations are bombarded by Founders/ CEOs/ Presidents visiting them all day. This conveys the image that a) your company is relatively small (the CEO of GM never personally sells you a car) and b) you are probably the most knowledgeable person in the organization about your product, but once you land the account the client company will mostly be dealing with newly hired second level staff. Monish recommends that Founder/ CEOs hand out a business card that has the title "Head of Sales" or "VP of Sales". By working in the Head of Sales role, and by your ability to speak knowledgeably about the product, you will convey the message that a) every person in the organization is very knowledgeable about the ins and outs of the product (even the sales guys) and b) you will personally be available to answer the client's questions over the long run. I've used this effectively many times myself.VR
-
For every success story in Silicon Valley, how many are there that fail?
It all depends on what one decides to be a definition of a "success story." For some entrepreneurs, it might be getting acqui-hired, for some -- a $10M exit, for some -- a $200M exit, and for others -- an IPO. Based on the numbers I have anecdotally heard in conversations over the last decade or so, VCs fund about 1 in 350 ventures they see, and of all of these funded ventures, only about 1 in 10 become really successful (i.e. have a big exit or a successful IPO.) So you are looking at a 1 in 3500 chance of eventual venture success among all of the companies that try to get VC funding. (To put this number in perspective, US VCs invest in about 3000-3500 companies every year.) In addition, there might be a few others (say, maybe another 1-2 in every 10 companies that get VC investments) that get "decent" exits along the way, and hence could be categorized as somewhat successful depending on, again, how one chooses to define what qualifies as a "success story." Finally, there might also be companies that may never need or get around to seeking VC funding. One can, of course, find holes in the simplifying assumptions I have made here, but it doesn't really matter if that number instead is 1 in 1000 or 1 in 10000. The basic point being made here is just that the odds are heavily stacked against new ventures being successful. But that's also one of the distinguishing characteristics of entrepreneurs -- to go ahead and try to bring their idea to life despite the heavy odds. Sources of some of the numbers: http://www.nvca.org/ http://en.wikipedia.org/wiki/Ven... https://www.pwcmoneytree.com/MTP... http://paulgraham.com/future.html Here are others' calculations of the odds that lead to a similar conclusion: 1.Dear Entrepreneurs: Here's How Bad Your Odds Of Success Are http://www.businessinsider.com/startup-odds-of-success-2013-5 2.Why 99.997% Of Entrepreneurs May Want To Postpone Or Avoid VC -- Even If You Can Get It http://www.forbes.com/sites/dileeprao/2013/07/29/why-99-997-of-entrepreneurs-may-want-to-postpone-or-avoid-vc-even-if-you-can-get-it/MB
-
How much equity should I ask as a C-level executive in a new startup ?
As you may suspect, there really isn't a hard and fast answer. You can review averages to see that a CEO typically becomes a major shareholder in a startup, but your role and renumeration will be based on the perceived value you bring to the organization. You value someone's contribution through equity when you think that they will be able to add long-term benefits, you would prefer that they don't move company part way through the process, and to keep them from being enticed by a better salary (a reason for equity tied to a vesting arrangement). Another reason is when the company doesn't have salary money available but the potential is very strong. In this situation you should be especially diligent in your analysis because you will realize that even the best laid plans sometimes fall completely short. So to get the best mix, you have to be very real about the company's long-term growth potential, your role in achieving it, and the current liquidity necessary to run the operations. It should also be realized that equity needs to be distributed. You cannot distribute 110% and having your cap table recalculated such that your 5% turns into 1% in order to make room for the newly hired head of technology is rather demotivating for the team. Equity should be used to entice a valuable person to join, stay, and contribute. It should not be used in leu of salary that allows an employee to pay their bills. So, like a lot of questions, the answer is really, it depends. Analyzing the true picture of your long-term potential will allow you to more easily determine the correct mix.DH
-
Whats are some ways to beta test an iOS app?
Apple will allow a developer to register 100 UDID devices per 12 month cycle to test via TestFlight or HockeyApp. Having started with TestFlight, I would really encourage you NOT to use it, and go directly to HockeyApp. HockeyApp is a much better product. There is also enterprise distribution which allows you far more UDID's but whether you qualify for enterprise distribution is difficult to say. As part of your testing, I'd encourage to explicitly ask your testers to only register one device. One of the things we experienced was some testers registering 3 devices but only used one, essentially wasting those UDID's where we could have given to other testers. Who you invite to be a tester should be selective as well. I think you should have no more than 10 non-user users. These people should be people who have either built successful mobile apps or who are just such huge consumers of similar mobile apps to what you're building, that they can give you great product feedback even though they aren't your user. Specifically, they can help point out non obvious UI problems and better ways to implement particular features. The rest of your users should be highly qualified as actually wanting what you're building. If they can't articulate why they should be the first to use what you're building, they are likely the wrong tester. The more you can do to make them "beg" to be a tester, the higher the sign that the feedback you're getting from them can be considered "high-signal." In a limited beta test, you're really looking to understand the biggest UX pain-points. For example, are people not registering and providing you the additional permissions you are requiring? Are they not completing an action that could trigger virality? How far are they getting in their first user session? How much time are they spending per user session? Obviously, you'll be doing your fair share of bug squashing, but the core of it is around improving the core flows to minimize friction as much as possible. Lastly, keep in mind that even with highly motivated users, their attention spans and patience for early builds is limited, so make sure that each of your builds really make significant improvements. Happy to talk through any of this and more about mobile app testing.TW
-
What is the best technology for developing a new mobile app from scratch?
There are two sides to that question. One is the mobile app itself and the other is the backend. If I misunderstood in any way and you didn't mean "native" app I apologize in advance. On the backend, there is no clear cut answer to which is the "best". It depends solely on the developers you are able to get. We for example use Node.js , mongoDB, redis, elasticsearch and a couple of proprietary tools in the backend. But you have your pick of the litter now both on the backend api and the datastore with the myriad of options available and touted as the "best" currently on the market. Now on the app side again it solely depends on what you need your mobile app to do. Experiencing first-hand "develop once, run anywhere" I can say it's more like "develop once, debug everywhere" to quote a Java saying. We have tried Phonegap and Titanium Appcelerator and we have switched to native (ObjC and Java) after a couple of months of trying to go the hybrid route. The reasons behind the choice are as follows: - anything that breaks the pattern of how those frameworks NEED to operate is just a huge technical debt that keeps accruing a huge interest. - anything that uses css3 accelerated animations on Android is buggy at best and slow as hell at worst on any lower (< 4.1 I think) versions of Android I hope this gives you some insight. If you need/want to ask me anything feel free to contact me. MihaiMP
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.