I have a Spotify developers key and have been preparing an iOS app for release that uses cocoalibspotify. Before I submit to Apple, I want to verify my account details and double check Spotify's approval process. But I can't find the info on developer.spotify.com for an iOS app - I just see details for a web app.
Could someone share hints or experiences of successfully publishing an iOS app that uses the Spotify API?
There's no formal approval process other than Apple's — just submit to Apple.
However, make sure you're abiding by libspotify's Terms and Conditions, particularly the fact you can't charge money for an app that uses libspotify.
If you'd like guidance, especially with your UI components (you must make it clear that music is being played from Spotify), contact the same team you would for web apps and they can help — contact details are on the Spotify developer website.
Related
I was looking online at the Spotify iOS SDK documentation and found this: "The iOS SDK is explicitly prohibited from use for in-car apps, re-streaming aka “listen together” apps, alarm tones, ring-tones, voice-assistants, and offline experiences for wearable or other devices." I was curious what was meant by "listen together apps." I was hoping to create an app in which users in the same place can queue up songs to a shared queue. Is this in violation? What if the users are all Spotify users? Can this be monetized?
Ari from Spotify here - we can answer technical implementation questions but can't interpret the Terms of Service for you. We recommend consulting legal counsel for help with the terms. Regarding monetization, all commercial integrations must be approved by Spotify. You can submit a request for commercial approval directly in the Spotify for Developers Dashboard by clicking "Create a Client ID" and then selecting "Yes" when asked about commercial use.
I'm finding it difficult to get a concrete answer on this, either I'm finding the wrong info or not comprehending what I am finding.
Our app will be available on the Play Store and App Store, as well as being accessible via Web App. We planned on using our website for customers to sign up, subscribe, pay, etc. The app will be a free download on the mobile app stores, with the free features active, only requiring a subscription for the advanced features.
Would this scenario (using Stripe for subscriptions, without any use of Google IAB or Apple IAP) break any developer agreements as they stand?
You will be rejected from the app store if you do this. Guidelines:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
If you don't want to bother integrating IAP, you can just exclude the payment stuff on the mobile client and let people do it on the web. Then, you can use your own verification mechanism to give people that have subscribed the correct content once they log into your app.
Spotify does something similar as described on their website. As far as how much of that they reveal in the app itself, you'd have to download it and see as I am not sure offhand. Your app may be rejected if it directly instructs users to go subscribe on your site.
The relevant info for the Play store is here.
Developers offering products within another category of app downloaded
on Google Play must use Google Play In-app Billing as the method of
payment, except for the following cases: Payment is solely for
physical products.
Payment is for digital content that may be consumed
outside of the app itself (e.g. songs that can be played on other
music players).
According to this, you are not required to use In-app Billing on Android since your content will technically be available on iOS and web as well.
I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired
elsewhere, including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.
I'm building a small app where users can browse cheap accessories like lipstick, nail polish, etc. I have Login With Amazon (http://login.amazon.com/) implemented because I originally thought that I could allow users to buy the accessories directly from my app.
But I soon realized that Apple has actually restricted that functionality. The purchase ability is available on Android and for web developers, but unfortunately not yet for iOS.
Is there some hacky way that I can allow users to make a purchase from my app (or from a web view in my app)? I have a little bit of experience with Python so I'm guessing there might be a way to write a script that presses different buttons on the Amazon web page in a web view in my app. The user is already logged in with Amazon.
You can use Shopelia SDK which enables in-app purchase of physical goods using one click payment. It is available for Amazon but also for any kind of retailers.
It works using a combinaison of automation and monetics to inject the order and process the payment.
Right now (October 2013), the product is in beta stage and can be demonstrated on Shopelia website http://www.shopelia.com
Integration is available through SDK for Android and iOS.
Disclaimer : I'm co-founder of Shopelia. Please contact me if you are interested to integrate the technology in your app.
I am developing an Application where I want the user to log in with his/her Apple ID.
Is this possible? If so, how can I do this?
Apple introduced Sign In with Apple at their worldwide developer conference, WWDC 2019.
Here's how Apple describe it:
Sign In with Apple makes it easy for users to sign in to your apps and websites using their Apple ID. Instead of filling out forms, verifying email addresses, and choosing new passwords, they can use Sign In with Apple to set up an account and start using your app right away. All accounts are protected with two-factor authentication for superior security, and Apple will not track users’ activity in your app or website.
Sign In with Apple requires iOS 13 or later, iPadOS 13 or later, watchOS 6 or later, macOS Catalina 10.15 or later, and tvOS 13 or later.
Nope, there is an standard API for this. You could use a UIWebView to make a user log in to an existing login form somewhere on apple.com, and then check for the subsequent success or failure URL, but that would probably be both brittle and rejected by the App Store approval process.
It is not possible currently. Your best bet is to submit a feature request at https://bugreport.apple.com/
If you want to authenticate users without setting up your own registration system, you could adopt Facebook Connect. Lots of people already use Facebook obviously, and you don't have to maintain the signup/forgot password/security stuff at all.
If you don't like Facebook, Google also offers a similar system. (see https://developers.google.com/accounts/docs/MobileApps)
Apple will probably never allow you to log in with the user's Apple ID.
You might be able to allow your users to log into Game Center. The user's Game Center account is tied to the AppleID, so users can be identified by your app that way. But this is assuming that you were actually building a game.
Apple's Game Center documentation is here: https://developer.apple.com/library/ios/#documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/15_GameCenter/GameCenter.html#//apple_ref/doc/uid/TP40011225-CH7-SW1
The App Store Review guidelines preclude using any information from Apple's services in your app, which is why it's dubious they would ever allow you to login with an Apple ID:
12. Scraping and aggregation
12.1
Applications that scrape any information from Apple sites (for example from apple.com, iTunes Store, App Store, iTunes Connect, Apple Developer Programs, etc) or create rankings using content from Apple sites and services will be rejected
If what you want to achieve is a seamless user experience between the user's different iOS devices without requiring the user to pick a username and password for your service you could maybe use iCloud. But of course it depends on what you are building. Apple provides some videos introducing the different iCloud APIs: https://developer.apple.com/icloud/documentation/