After reading Apple Developer Program License Agreement I have some questions about a usage of Local notifications and APN:
There is a paragraph in Agreement (Attachment 1 ยง2.2):
You may not use the APN or Local Notifications for the purposes of advertising, product promotion, or direct marketing of any kind (e.g., up-selling, cross-selling, etc.), including, but not limited to, sending any messages to promote the use of Your Application or advertise the availability of new features or versions. Notwithstanding the foregoing, You may use the APN or Local Notifications for promotional purposes in connection with Your Pass so long as such use is directly related to the Pass, e.g., a store coupon may be sent to Your Pass in Wallet.
In my game I want:
a) notify user via Local Notifications after a long (several days) inactivity in the game (every app launch will snooze a notification for a few days ahead)
b) notify users via APN about new levels are available to download
Is APN and Local Notification are legal to implement a) and b)?
Although this is not a programming question as #Mojtaba Hosseini said in comment:
Yes. You can advertise anything about your app and it's levels and features and it's completely legal. But you should not advertise anything that is not related to the current app that received notification.
Related
I have an app that creates pdf's for the user. When this app creates a new pdf (say on the users i-pad) I want the iwatch to display a notification saying a new pdf has been created.
Does this require a server, it was my understanding apple could provide this service.
Any help or tips would be appreciated!
First to address the difference between local and push notifications. Local Notifications would be used on the specific device the user is on at the time, and is normally scheduled for a specific time such as the reminder app notifying you at a scheduled time. Push notification are sent via a server to other devices.
Since you want to send to the other devices you will want to implement push notifications. In order to do this the user will need your app on all devices. Additionally you will need to have a login system so you know which devices belong to the same user. From there you will need a push notification service that can do targeted push notifications. There are many services out there and you will need to decide which one is right for your situation.
Push notifications are sent to the device by using the device token Apple provides after the user approves notifications for your app. Each app on each device has their own device token. So in addition to targeted notifications you will want a push service that allows you to setup channels such as parse.com, that way you can setup a channel specific to each user (email, username, or ...). Then when your user logs in on any device and approves getting push notifications, their channel will be set to (whatever option you choose) and you can trigger the push notification to the specific channel and will send the notification to any device.
There are other consideration but this is a good place to start.
Local notification is just that, local to that device. Remote notification is what you need. You will either need to create a server for this purpose or use one of the variety of third-party services (Urban Airship, Parse, etc) to provide that functionality.
Clarification point -- when you say:
I want their iphone, and every other device that they have to receive a notification that a new pdf has been created
it is assumed that you mean "every device of theirs that is running your app and has approved notifications from your app". If you're trying to piggy-back on some magic AppleID-related foo, that won't be possible.
I'm currently struggle with annoying store-and-forward function limitation of APNS. Here is a quote from the Apple docs:
If APNs attempts to deliver a notification but the device is offline,
the notification is stored for a limited period of time,
and delivered to the device when it becomes available. Only ONE recent
notification for a particular application is stored. If multiple notifications
are sent while the device is offline, each new notification causes the prior
notification to be DISCARDED.
I specifically make ALL CAPS for the keywords of my problem. In Google Cloud Messaging notifications service their store and forward function have much more capabilities:There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. - so Google service can store up to 100 push messages for a max time of 28 days. And in addition to this they have also coalescing (collapsible) notifications but for 4 different collapsible messages. And in APNS all we have is - one recent
notification for a particular application is stored - it is quite a limited behaviour for my app (I need to store at least four different push notifications while the device is offline at one given moment of time).
So I'm interested are there some ways I can improve store and forward capability of APNS?? Can I in some way make APNS to store more push notifications for a specific device?Or at least store several coalescing notifications as in Google collapsible messages? Some third party solutions or whatever? May be I missed something in APNS docs? I know we can orchestrate apple push notification on google platform - but I think it is not a solution because of its unjustified complexity.
As you found yourself in Apple's APNS docs, there is no way to store more than one notification per application for a single device. If you want to compare it to GCM, APNS server acts as if all notifications have the same collapse key.
No third party solutions can work around that, since Apple doesn't return an acknowledgment of delivery to the sender of the notification, so the server (whether it's implemented by you or by some third party provider) has no way of knowing which messages to store and resend (assuming that all the messages are valid and were not rejected by APNS server).
Apple Push Notifications are not intended to deliver important data. Their purpose is to notify the user of the app that new data is available at the server, which allows the app to load that data if the user chooses to open the app. That's the reason why they don't store more than one message per app for the same device.
We are planning to develop the push notification service for a telecom operator. But I haven't got any information whether the APNS push service is free of cost or should we make any payment?
My questions are,
Should I pay for using the APNS push service?
If operator want to sent push notification to millions of subscribers, should we pay to Apple or is it absolutely free? If not free, please share the URL where payment details are available.
Is there any limit for the number of notification sent or the number of subscribers?
Apple does not charge a separate fee for utilizing the push notification service.
Your only cost is a server that will be sending the push notifications to Apple. There are third-parties that provide this servers and there is a fee for that.
Answer for your question 1,2 and 3 is: Apple doesn't charge you for APNS - but you have to maintain a server for pushing.
Try these third parties for pushing,
PushWizard, a free and unlimited push service.
It can send 250 million push messages / hour
and PushWizard is free for unlimited devices, while other services can be very expensive if you have more, than 1 million users to reach at least ONCE per month.
Monopush, which provides a RESTful API and a lot of free push alerts up-front to handle the server infrastructure for you.
You need just copy and paste a few line codes to inside of your application and then magic will be started. After that you can start to watch, analyze, categorize your clients and you can send push messages to them as well as resource messages.
As mentioned above, Apple does not charge for the APNS
However, you need to maintain a 3rd party server for that, and sending notifications to millions of devices would require a lot of work from you.
There are some very good industrial solutions for iOS push notifications service that use APNS:
PushApps - free for 1M notifications per month, and unlimited notifications for 19.99 per month - here is the documentation
Urban Airship - free up to 1M notifications per month, afterwards you are charged per 1000 notifications
PushWoosh - free for 1M devices, premium plans are from 39 EURO
Diclaimer - I work in PushApps and also use their product in my applications for over a year now.
Please refer the following:
APNS is a free service. However, you need to maintain a server to send Push Messages.
Apple Local and Push Notification Programming Guide
There are many online servers which provide you free push services [for limited pushes/users/devices]. They do have plans depending upon the needs of client. Following are the few ones:
a. Parse Parse not available anymore. It is now acquired by Facebook. Read More Here
b. PushWizard
c. Xtify
d. SetUp your own push server - this tutroial comprise of complete end to end steps of how to send push messages to iOS Devices.
Hope this helps.
Although push notifications are usually send from 'servers', it is not necessary to own a server or to pay a service. Instead it is also possible to send pushes from your personal computer or mobile device. Especially for testing purposes, this is very useful. Try:
NWPusher
APNS-Pusher
My company offers an iPhone app for day traders which basically tells them when it's a good time to buy or sell. A cluster of servers generate these BUY and SELL signals and need to be delivered to a customer's iOS device in a minute or less. For all other mobile clients we've developed, we are allowed to poll the server in the background (once per minute), to check for updates.
In iOS, however, it seems that doing anything in applicationDidEnterBackground that has to do with times or polling isn't an option.
This led me to look at push notifications, but from what I am reading, they aren't reliable. They employ a send-and-forget methodology, which there's no guarantee they will be received.
You can see the problem with this. If we issue a BUY signal and the user acts on it, then a SELL signal is generated 10 minutes later and send via push, but never arrives, they could lose a lot of money.
So, is there a good way to do this or am I out of luck? Thanks!
There are two intermediaries between your server and the user's device: a) Apple and b) the network.
Apple does not guarantee the delivery of all notifications; only the most recent is guaranteed to arrive and only for a limited period of time. For more information, check out the "Quality of Service" section in Apple Push Notification Service.
If the device is accessing the network through a mobile carrier, things may get ugly. I have experienced situations where, some notifications didn't arrive until much later, and some got lost entirely. From my experience, carriers protect -with zeal- the quality of their own services, rather than those of third parties like Apple. An SMS/MMS will not normally be lost, while a push notification might.
Polling the server would be a viable alternative for your app. Alas, Apple doesn't allow networking operations to take place for apps that have been put in the background state (except for Newsstand downloads and VoIP).
Some apps seem to do push notifications really well (GroupMe) while others don't. If you're really worried, you could use a service like Twilio to send the user an SMS message with a link that would open your app and give it some information. So the SMS could say "SELL SELL SELL yourapp://stock=APL" or something like that. This obviously won't work for iPod touch users or iPad users (although I don't know if that will be a problem for you.
Try using Apple's own push notification service: http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
It's quite easy to implement, with just a few lines of code in the application and a bit of PHP and JSON on the server to do the sending. The good thing is that your server sends the request to Apple, and Apple's own servers handle the delivery to the device securely and reliably. Notifications are usually delivered within 10 seconds of being sent (unless the device is offline, then it will be delivered when the device comes online).
From my experience with push notifications, I haven't lost a single one, and there is a delivery option that continuously attempts to deliver it until it is successful, and there is even a server side callback API of some sort available that lets you check the status of your notifications. You could also try a service like Urban Airship to do the work for you.
You could also try using one of Apple's background modes as part of this (such as receive the 'BUY' as a notification and have the app wait for the 'SELL' in the background. The biggest limitation is that the app can only run in the background for about 10 minutes at a time, so you would have to use a workaround like playing music in the background (or making stock announcements like a music track ;P), or prompting the user to reopen the app to continue the background session.
Is there any limits/restrictions about amount of notifications sent to the APNS in time range?
For example - can I send 100,000 messages for 100,000 devices (one message for one device) in one hour to notify them about new content available to purchase via in-app purchases ?
Found nothing about any restrictions in the manual.
I don't think there is a restriction for number of messages sent in a time frame. But I guess in your case, it is unclear, if it violates rules stated in review guidelines 5.6 and 5.8
5.6 Apps cannot use Push Notifications to send advertising, promotions, or direct marketing of any kind
5.8 Apps that excessively use the network capacity or bandwidth of the APN service or unduly burden a device with Push Notifications will
be rejected