How often can my Application send APNS Notification - iphone

I need to send remote APNS notifications from my server application to my iPhone applications. I want to know the frequency with which I can send remote APNS notifications in the following scenarios:
From my server application to the iPhone application on the same device.
From my server application to the iPhone applications on different devices.
I know that Apple has set some limit on this, but I do not know the limit.
Thanks

As per my information Apple has not specified any specific limit but following text in programming guide of service.
Apple Push Notification service continually monitors providers for irregular behavior, looking for sudden spikes of activity, rapid connect-disconnect cycles, and similar activity. Apple seeks to notify providers when it detects this behavior, and if the behavior continues, it may put the provider’s certificate on a revocation list and refuse further connections. Any continued irregular or problematic behavior may result in the termination of a provider's access to APNs.
Following paragraph is given here
If you find any further details then post here......

Related

If I run my own push notification server do I still need FCM?

I've just read alot about push notification servers, self-hosted ones as well as cloud. and I am pretty much confused about one aspect.
I need push notifications for my Android/iOS app for more than a million devices using the same app. now there is no free service for that scale and paid services will result in too much monthly fees, so I thought about running my own server with an open source solution. I've checked Many but parse seems to be the best fit. but they say that it uses FCM and I know from google pricing that it is free only for a limited number of registered devices. I thought that hosting my own push server would spare me those fees; but it seems like not; what good is it then ? wouldnt it be better to just use FCM directly ?
Delivering push notifications to Android (with Google Play Services) and iOS will always use FCM or APNS respectively. The reason is that those services are built into the operating system, or built closer to the operating system than regular application can function and get reliability and battery life advantages from that. Both FCM and APNS are completely free and unlimited, although both have quota to protect the services against abuse.
There are many services (such as Parse Push, Airship, OneSignal, etc) that build on top of FCM and APNS to provide higher level messaging operations. But at a lower level these will be using APNS and FCM for the actual delivery of the messages.
That's also what you have to think of when you considering building your own server: what will that server actually do to deliver the messages to the devices? If you're not using FCM/APNS, how do you get the message to the device, especially when the user is not actively using the app?

Sending Message iPhone to Any iPhone over Wi-fi ( Data) across world

I want to develop an application which sends a Message from iPhone to other iPhone over the internet, I want to receive the Message from other iPhone even if my iPhone is running in the background.
I have seen the WiTap application, but socket will get disconnect when application is closed or if there is screen lock.
So is that possible to develop the application so that I can receive the message even if my app running in the background forever?
From my little Knowledge, You can't do it through WiFi.
When a screen lock happened, device will automatically OFF the wifi connection for increasing battery life.Thats why socket connection getting disconnected.
In iOS, apps can’t do a lot in the background. Apps are only allowed to do limited set of activities so battery life is conserved.
But what if something interesting happens and you wish to let the user know about this, even if they’re not currently using your app.
For example, maybe the user received a new chat. Since the app isn’t currently running, it cannot check for these events.
Luckily, Apple has provided a solution to this. Instead of your app continuously checking for events or doing work in the background, you can write a server-side component to do this instead.
You can do it using Apple Push Notification Service.
It uses push technology through a constantly open IP connection to forward notifications from the servers of third party applications to the Apple devices; such notifications may include badges, sounds or custom text alerts. In iOS 5, Notification Center enhanced the user experience of push and local notifications.
More details are here
Note: details and screen shots are taken from raywenderlich website/blog.

Anyone using XMPP to implement Push Notifications on iOS?

I'm looking for any reference projects or key learning from anyone who has implemented XMPP/Jabber to successfully send notifications to iOS devices (iPhone/iPad).
I'm considering using an XMPP server (OpenFire specifically) to provide a single cross platform mobile push system. C2DM for android has a number of annoying requirements like users having Google accounts. This is what got me started looking at XMPP. I also need to support pushing to iOS devices. I know all about APNS, however I'm wondering if I could use the XMPP server for both Android and iOS platforms (and possibly more like Black Berry).
The things I feel might come up are:
iOS killing any persistent connection to the XMPP server. Will it
auto reconnect?
iOS preventing access to certain ports or protocols.
Anything to be aware of here?
Other gotchas one would only discover
by trying this?
Here you can find the answer to your first question:
when your app goes in background you (the client) close the connection
with the xmpp server. When your app comes back into foreground you
reopen the connection. If your server need to send messages to your
client, it must use push notifications. When the client receives the
notification can (it depends on the user action) go back to
foreground.
(source: iOS Backgrounding & XMPPFramework)

How can a back-end server connect to a specific iphone?

It is very usual that an iPhone send data to internet server.
But what if a server wants to connect to an iphone?
I have wondered long about it.
For example, like many web-based apps like Facebook, what is the mechanism/algorithm behind, so that when, for example, any updates on your wall can be noticed to you in a real-time manner?
Hope some can understand my query.
Have a look at this Wikpedia article about Push Technology.
Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. It is contrasted with pull technology, where the request for the transmission of information is initiated by the receiver or client.
Your iPhone could intermittently 'poll' the server, looking for any data it needs to be sent. Say every 5 seconds, or after some trigger - it would call the server and ask for new data.
You could use push technology: i.e. have a continuous http connection open to your server that allows data to be sent both ways. LightStreamer is a product that does this that i've used before. This is the most elegant and efficient solution for streaming data.
You could use iOS push notifications. The server can trigger a push message and target it at a specific device and send your iPhone something...
Push notifications are the way to go with iOS. I have used push notifications through the cloud-based Cocoafish backend server. This is a great solution as you can 'subscribe' mobile devices to a push notifications channel - for example, a channel for friends requests or a channel for chat etc. Its real easy to set up with all the correct certification. There's good set up instructions in the documentation on their site too.

Can an iPhone app act as a server to send messages or push notifications?

I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.