I'm looking for a way to download iPhone apps (or just the .app content of the Payload folder) as an in-app purchase.
I work with a company who has built their entire asset library in Flash and we're now trying to get it mobile. I know this isn't ideal but with Flash CS5.5 we can export the Flash to a .ipa. While we could ship each course as its own app, we're trying to achieve a more streamlined experience (think the Marvel Comics app). Ultimately I'd like to write the Container App in Xamarin.
Is there anyway to make these "apps" or their payload non-consumable content through an in-app download and can someone point me in the right direction for launching them? I'm not trying to get around Apple's security provisions or in-app purchasing rules so any input would be greatly appreciated.
Apple does not allow IAPs to be code. You can't use IAPs to distribute apps. You can have an advertisement in your app that features the other apps, but there's no mechanism to purchase one app from another.
Related
I am in the process of developing an app which needs to have a monthly subscription in-app purchase. The first version will be on the Apple platform. I have developed it using Xamarin because it need to support Android later as well. So far so good. Now I would like to start the development of the same kind of app for Apple TV, but I would like to use Xcode and Switch for that (because I prefer that). Is there a way to share the in-app purchase between the two different apps? I was first thinking of using wildcard for my bundle id, and use the same, but that does not seem to work for in-app purchase? Or am I missing something?
Thanks
I am developing an app that I would like some people to download it. Specifically, the people who attend my event. I've looked into the different ways of doing that, and I couldn't find how to do it. Is there a way to do it other than the App Store? Like a download link or an email attachment?
Scenario: I have an event taking place at some venue. People who attend must download an app before entering the place.
You can use TestFlight or the iOS Enterprise Program
TestFlight
With TestFlight, you can let people 'test' your app. You can setup up to 25 internal testers and 1000 external testers to test your app.
Maybe it isn't exactly, what you are looking for, but it's the cheapest way.
They then can download the TestFlight-app and will see the apps which they are invited as beta-testers. It's a very easy and nice possibility, because you also can update your app and the testers will receive updates.
Check this tutorial how to make a proper setup to do that.
iOS Enterprise Program
With this special program which costs 300$/year you can install your apps within your enterprise. But your company must be a company with a D-U-N-S number to apply. Check the details on the apple website.
You can also use Diawi.com for that matter.
PROS:
1. Easy to use. Just drag the IPA file and the Provisioning Profile to the upload box. Wait for it to get uploaded. Generate Link. Send the link to your intended downloaders. They can download it super easy and fast.
2. No need to pass the app review in Apple.
CONS:
Few Users can download. Only the registered devices in your Apple Developer account can download the app which is limited to 100 and is renewable only for once a year.
If you intend this app for people not more than 100, use this. Otherwise use TestFlight that is already integrated in itunesconnect. The cons only is that the app needs to pass the review. Pros, up to 1000 people can download it.
Hope it helps.
Let's say I sell video-tutorials using a credit system and I want the service to be available as a website, an Android app and a iOS app.
So users may buy/consume credits and use credits to purchase video-tutorials from one of those 3 sources.
From Apple guidelines I read:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be
rejected
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected
11.4 Apps that use IAP to purchase credits or other currencies must consume those credits within the App
11.5 Apps that use IAP to purchase credits or other currencies that expire will be rejected
Is it totally prohibited to use a credit system shared among many access points (as website, android, ios, windows and so on..) or it can be done just avoiding IAP (Apple in App purchase) and using for example PayPal mobile SDK?
It seems very strange to me that apps with this functionality cannot be published.
The only points in apple guidelines referring to credits (or virtual currencies are) 11.4 and 11.5 which make me think you can actually make an app that does not use IAP to purchase credits.
And if you can make an app that does not use IAP to purchase credits you don't have to respect point 11.4 so you can actually consume those credits outside the app itself.
BUT: given that you can sell credits without using IAP and so consume them even outside the app, using them to buy content will break points 11.1 and 11.2 ?
Thank you very much
I am not 100% sure about this, but based on other apps i have seen and the reason why other apps have been taken down i can think the following.
If your app uses the apple app purchase, then its fine.
If your app uses credits that came from another place, its also fine.
However, these credits SHOULD ONLY be purchasable using the in app purchase when the user access your service through the app. This means, you shouldn't offer any other "way of purchasing" credits while the user is using your app.
As an example i remember a very famous app, which i don't remember which was it, had to be taken down because it showed a link that would let users access the desktop purchase system, directly from the app.
There is also other examples. There are a ton of dating applications that use this system, if you go to their websites you can purchase credit, or you can directly purchase them within the app using the in app store method, the credits are the same for the service, just the way of buying them changes.
Another example is the game hearthstone, you can buy decks in game, but you can also buy them from their website, its not the same as credits, but the main point is the same.
Basically, what i think it means is, money related operations should go through apple if the service is being accessed by your app regardless of anything else.
You might want to wait for someone who has had more experience in this, I am just telling you what i have noticed.
I'm trying to set up my newsstand application for iOS.
I've made Auto-Renewable Subscription In-App Purchases for subscription, I've made Non-Consumable In-App Purchases for single issues, so it's ok, but one thing still bothers me.
iTunes Connect Developer Guide says "You can enable your app for Newsstand from the app summary page for an app by clicking Newsstand.", but I still unable to get the purpose of this. What's the use of issues I add under this button?
Is there is a way to get this list of issues from my app? Or why it is there?
This is for purposes of covers being shown in iTunes Preview / App Store. If you don't use it at all, the covers won't change, however using Atom Feed to update them seems to be better solution.
You can find how to use it here: https://itunesconnect.apple.com/docs/NewsstandAtomFeedSpecification.pdf
If I have a both an iPhone and iPad version of an app, can they share in-app purchases? If a user makes a purchase on their iPhone, then downloads the app on an iPad, I need the app to respect the purchase.
I have a lot of artwork files so the app is fairly large, and I'm wondering if separate apps are the way to go in this case, instead of a universal app.
So it is possible to share in-app purchases with two different targets? I have read a few things that mention iCloud in this scenario, but have no idea how that would work.
No. In-app purchase products are associated with apps bundle IDs. You'd need to go with an universal app.