I'm implementing server-to-client communication in my iOS Application. What I'm trying to do is to deliver new messages from server to client such as
Old version will be no longer support soon, please update asap.
There is a new content available.
Reminder of some interesting content.
etc.
When device got message, it will notify user by showing "You got new X messages" with badge number. After user launch the app by clicking at the notification message, it will show those message containing images and text within my application.
At the beginning, I did this by iOS 7 background data fetch because the message content size that I mentioned will contains image url and text, it may exceed the maximum size of push notification content length. After testing with that approach, I found that there is no guarantee of when the application will be wake to connect and fetch new message from my server. (I left the device overnight to see how many time it connect to my server, first night was 5 times, second night was once)
Since some of the message is time sensitive (like reminder), I came up with the another approach by sending a Push Notification to the device when there is any new message to signal the app instead. But, according to App Store Review Guideline
5. Push Notifications
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
So, my questions are,
If I send a message contains promotions or marketing material but it won't showing at the iOS Device home screen, instead, user has to launch my application to see those contents, will it be the case of 5.6?
From 5.8, "excessively use the network capacity or bandwidth", do you know how many notifications can be sent to how many devices per time period? If I send 2 notifications to thousands of devices every hour, will that be the case?
Thank you, in advance.
5.6 wont be a problem, because i developed few which is working as like your scenario and they are live in app store.
5.8 also wont be problem i think, because i saw few application using push notification for voice call and video call application for intimate new call arrival for the user.
Some chatting application also using APN for intimation the user when
new message arrived for that user.
Related
I got a question that i can't figure out a long time. I know that i can't sync my application in "not-running" state. But let me show a simple scenario:
I killed WhatsApp. It's not running.
I send a message from another device.
Remote notification received and alert shown.
I activated "plane mode" on receiver device.
Then i launch WhatsApp.
It can't sync messages because of "plane mode" but i saw new message that received with remote notification.
I tested this scenario on iOS 9 and iOS 10 devices. How does it posible? Can anyone explain this?
I think they are using Remote Notifications background mode.
"If your server sends push notifications to a user’s device when new content is available for your app, you can ask the system to run your app in the background so that it can begin downloading the new content right away. The intent of this background mode is to minimize the amount of time that elapses between when a user sees a push notification and when your app is able to able to display the associated content. Apps are typically woken up at roughly the same time that the user sees the notification but that still gives you more time than you might have otherwise."
This is from developer apple. You can read more detailed about it in this artice under "Using Push Notifications to Initiate a Download".
Hope it will help.
Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.
a simple question: is it possible to get a message, notification or similar when the internet connection is available when app is killed or not running?
For my purpose, I need a way to synchronize all my notifications because APNs can send only the last message.
EDIT:
I'm wondering how some apps (e.g. whatsapp) are able to sync their notifications when the internet connection is up. If I kill whatsapp, I can receive multiple notification when internet connection is reachable, but the APNS server provides only last message and, for this case, I'm not able to send silent notification. If I should develop a chat application, what are the best practices to work with Apple notifications?
If you send a push notification with a title, text, sound and/or badge property while the app is suspended (was killed / force closed), the device will still receive it, e.g. will show the text as a notification, play a sound and/or change the badge count.
However, your app won't be launched or woken up in the background in this case, so you have no way to handle the notification before the user taps on it. (See this question:
Will iOS launch my app into the background if it was force-quit by the user?)
So if the app was force closed by the user, your only option is to send a notification to be displayed as it is and if the device is offline, only the last notification will be received and displayed by the device.
For more control, you could use silent push notifications to implement "push-to-sync". In this case, the push notification only signals that there is new data to be fetched. The app (if not force closed) loads the data from the server then and triggers local notifications with the right data in the right order. But this won't work, if the app was force closed.
Apple push notifications have a lot of restrictions, so you won't be able to implement a perfect solution. In my opinion, it's fine if the user gets only the last notification when the device gets online after being offline for a while. At least he is informed that there is a new message and after opening the app, he can see the other new messages too. For the "push-to-sync" scenario, I would say that the user has no right to expect that the app works as desired, if he force-quits it.
Push notifications were never intended to be used in the way they are used by a lot of apps by now. E.g. they shouldn't contain sensitive data such as a chat message. They were intended to inform the user that there is new data for the app, so he can launch it to see the new data. E.g. instead of sending the actual chat message text a push notification should just contain the text "You have a new message". Then, you don't have the problem you described. Of course this is a terrible solution in terms of usability.
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.
A very simple task that took me 30 minutes to implement on an android.
A web server sends a message to device. Without user interaction a receipt is sent back. User understands that this is a desired behavior. When user opens the app he/she can send additional acknowledgement.
My understanding is that as long as I am not using location service I cannot run app in background continuously (or periodically). Push notifications will require user interaction, otherwise it's just a badge and a message.
This seems like a trivial problem but makes my head hurt and want me to give up.
Is Enterprise subscription the only way for me to get the app to our company users?
First you need to ask user permission to send PUSH notifications. Once the user agrees for you to send PUSH notifications to his device, you need to get the device ID and store it in your servers. This is the FIRST phase of PUSH-NOTIFICATION
In the next phase (SECOND phase), lets say you want to notify the user about something, what you do is get all deviceIDs for that user (he might have registered more than 1 iOS device) and send some X message to his device(s) leveraging apple's PUSH infrastructure. You need to pass the deviceID's to Apple (along with a bunch of other stuff) as this is how it identifies which device gets this X message.
Also initially while registering for PUSH, you need to write a little code to configure how your PUSH notification will look like. Would it have SOUND, BADGE, MESSAGE etc.
For all this to happen you as a app developer do not need to concern whether you app is ACTIVE or not. iOS takes care of it. After the initial PUSH registration the user too is not involved. You dont need to run your app in the background nor do you need to register for continuous location updates.
Have I understood your question correctly?