I have gone through a lot of articles on internet and most say that IOS applications allow IPC using protocol handlers (URL Schemes). But, Can't we achieve IPC using sockets, if one application opens a port and the other tries to connect to it ?
iOS8 introduced IPC support by exposing mach ports for so called "application groups". Check out this great tutorial:
http://ddeville.me/2015/02/interprocess-communication-on-ios-with-mach-messages/
It requires a bit of setup (to define application groups in dev portal, generate proper entitlements, etc..) but is not really so difficult and Xcode 6 does most of the job automatically (just enable "App groups" in general capacities section).
I can confirm, it works (I was able to create 2 apps sending messages to each other).
On iO7 there is no official support for IPS, but If you do not plan to upload your app to AppStore, you could try to exploit inter-app audio communication to achieve this.
Check out Apple's code sample, which demonstrated inter-app sound data stream between 3 apps:
https://developer.apple.com/library/ios/samplecode/InterAppAudioSuite/Introduction/Intro.html
Associated WWDS video:
https://developer.apple.com/wwdc/videos/#602
I haven't try to exploit it for non-audio usage but can't see the reason why shouldn't it work. Data rate is great, and sound data are just bytes and do not have to be redirected to the speaker, but interpreted however you like.
Of course, it will be rejected in AppStore review, but it is still fine for enterprise or own usage.
No, it is not for several reasons. 1) Apple does not allow this internally and has security layers to prevent this. 2) Applications fire applicationDiD/WillEnterBackground after a short delay, at which point the way you can interact with it plummets.
If you really want to send data between applications, set up a server with certs to match your app so you can use APN (apple push notifications) to send data in silent pushes to applications. Then, set up endpoints on the server that trigger those sends, and have apps consume the API that the server exposes.
Related
I'm trying to write a super-simple iOS app, just for personal use (i.e. it doesn't need to conform to any App Store stuff). I want it to do the following. Assume it's installed on two devices, both of which I own/control.
On device 1, it has a button that, when pressed, will immediately cause a notification to pop up on device 2.
I'm fine with hardcoding specific apple IDs, device IDs, whatever; it's also fine if this only works when the two devices are on the same LAN/Wifi. all I want is for the above to work, in the easiest way possible, and preferably without needing anything to run on a server anywhere.
How simply can this be implemented? I've set up a whole push-notification system once before, but that required some server-side stuff. Hoping to be able to do this without any of that.
====
Update: realized I wasn't clear in the original post that I need the notification on Device 2 to pop up whether or not the app is currently open/running on that device.
I think that what you are searching for is multipeer connectivity framework.
The Multipeer Connectivity framework supports the discovery of
services provided by nearby devices and supports communicating with
those services through message-based data, streaming data, and
resources (such as files). In iOS, the framework uses infrastructure
Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area
networks for the underlying transport. In macOS and tvOS, it uses
infrastructure Wi-Fi, peer-to-peer Wi-Fi, and Ethernet.
source: https://developer.apple.com/documentation/multipeerconnectivity.
You can also check those tutorials:
https://www.ralfebert.com/ios-app-development/multipeer-connectivity/
https://www.hackingwithswift.com/example-code/networking/how-to-create-a-peer-to-peer-network-using-the-multipeer-connectivity-framework
Send sms to port is a way (the protocol will become SMS): https://developer.apple.com/documentation/foundation/nsportmessage
and Maybe Firebase Remote Config can help you: you can get your data in FCM remote config (key-value) from the app :
https://www.raywenderlich.com/17323848-firebase-remote-config-tutorial-for-ios
https://firebase.google.com/docs/remote-config/get-started?platform=ios
, and you can modify your data whenever you want, and the app can fetch it.
I have similar requirements, and it seems like APNS (Apple Push Notification Service) is required for this because it's one of the only ways to 'activate' an application that is in the background.
As a result, then the question is how to make APNS as painless as possible? It seems like combining Firebase Cloud Messaging (or FCM) (to manage APNS / sending messages), and Firebase Functions (to help manage FCM server-side requirements) is one decent option.
So basically I have two iOS apps installed on the same device, and they need to communicate by sending data to each other. I don't want to use URL scheme or Universal links as these two would open the other app in UI instead of sending message to each other in the background. Currently I have a solution of using a unix socket connection by binding one app to a specific port and have another app connect to it. This works fine but I am just wondering if Apple would allow the usage of this.
Note that these two iOS apps do not come from the same developer so anything else that relies on App Group would not work in this case..
Would Apple allow using a socket in this case?
Edit: One of the app is valid to run in background, so background execution is not a problem
No, this is not possible simply because the application will lose network connectivity when it goes into background mode. I invite you to check the following Apple Developer Documentation page related to iOS app background modes:
Background Execution
As you can find on the page, the operating system suspend the app when it moves to background and will then cut several resources including network access.
There are however some exceptions to the rule, which are voice ip apps. These must declare the voip background mode in the plist file to be allowed to keep network streams open in the background.
This question comes a lot on iOS or Android and unfortunately the answer so far is no, we can do tcp client / server communication between apps.
It is totally doable as long as one of your apps has permissions to run on the background. Such example is music apps. Spotify does the same thing with their “app-remote” SDK.
If I have both a native app and a progressive web app using web push notifications powered by service worker, is there a way to prevent a user from receiving duplicate notifications if they opt in to receiving notifications from the web site and also have the app installed?
In short - there is no easy way to do this today.
There is a discussion on Chrome here on this: https://code.google.com/p/chromium/issues/detail?id=402223
The last comment from October 2015:
For now the safest minimal solution is for sites to provide an easy
opt out mechanism (which we strongly recommend you do anyway!) so
users can turn off notifications from one platform
Another possible heuristic based solution is to take some measure for
which interface (web or native) the user most often uses (or most
recently used) and only send to that. Combined with grouping these
devices by rough screen size should give a pretty good approximation.
The issue is that if the user has two similar sized devices and uses
native on one and web on the other then notifications will only be
delivered to one, which is an edge case.
We've also been discussing building an API so sites can tell whether
their corresponding native app is installed to avoid this case, but
need to start discussing that with other browser vendors to see if
they'd be supportive.
I have just delivered a prototype for a big client, everything was fine but I'm now curious to know if the solution/architecture I've chosen was the right one or there's place for improvement in case the project will keep on.
The task was to build two iOS apps: one running on 5 different iPhones, and another running on 2 iPads. Basically the iPhone applications had to communicate information to the iPads, and occasionally they also had to send information between each other (iPhone to iPhone). All the infos where small JSON objects/chunks whose size was small, really small.
The app was not intended to reach the app store, is a working prototype to test out some ideas in a user testing environment.
I discarded bluetooth because we are talking about a peer-to-peer communication, not a one-to-one.
What I did was to use web sockets thanks to SocketIO, through a small Node.js server that was running on my mac. The server was really simple, just receiving the messages from the clients and broadcasting information to the other ones.
What do you think? Is the solution I've chosen ok, or there are better ones?
For example, this morning I've just found out these thread here on SO, and I've discovered I could have used GameKit. What do you think?
Socket.IO is nice because it is fairly simple to implement but it has the downside of requiring a central server. If you wanted to avoid that, you could use the Multipeer Connectivity framework that was introduced in iOS 7.
It will let you create one-to-one communication channels between devices on either the same WiFi network or Bluetooth. Once the channel is created, you can send whole NSData objects (or create streams but it doesn't seem relevant to your use case).
A good read : http://nshipster.com/multipeer-connectivity/
The WiTap sample from Apple demonstrates peer-to-peer networking over Wi-Fi and Bluetooth. Using Bonjour, the application both advertises itself on the local network and displays a list of other instances on the network. Supports infrastructure networks, peer-to-peer Bluetooth, and peer-to-peer Wi-Fi (on compatible hardware).
I have personally tested it and it works fine and well documented.
I think socket.io is the best choice. It is built on top of engine.io (which in turn is built on the fastest websocket implementation: ws) It has oldest to newest fallbacks, so it starts with long polling and works its way up. This guarantees a quick initial connection instead of needing to poll the device for features. You can read more on this here. Best of all, it handles everything seamlessly. You write your code as if websockets are supported on connecting devices and if not it will use other methods behind the scenes.
This post details many of the websocket libraries you could use with your server. Which websocket library to use with Node.js?
I am convinced Bonjour is the best solution:
Apps can also leverage Bonjour to automatically detect other instances
of the app (or other services) on the network.
However I've never used it myself; perhaps someone who has can comment?
I'm trying to make an iOS 5 app that features real-time things coming from the server. It will only use these whilst the app is running.
To make it real-time without polling I have been evaluating two design routes:
Creating a socket from the app to the server, and exchanging information via streams.
Pros: Relatively simple and would not involve a 3rd party.
Cons: Battery life drain.
For an overview of how this might work, check
out this excellent tutorial:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Using standard HTTP to communicate with the server, and with each request from the app let the server know what they are viewing. If something new is available for user, send an Apple Push Notification (with no visible alert) to let app know it can go and download new thing.
Pros: Not opening up a new TCP connection, so battery life not drained unnecessarily.
Cons: Feels like a poor hack.
The official docs on APNs http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
I think a socket would be the way to go, but before I commit to it I wanted a second opinion, as this is the first time I've made anything like this!
Sockets would be my choice. I do not know how time critical your application is, but sockets might perform better as APNs if realtime is a must.
Does it really need to be "full real time"? From my point of view i would prefer http since it is already well integrated into the iOS SDK. Its easy to understand, maintain and implement and plenty of documentation is on the web. So maybe a http poll every minute or so will be enough (depending on the app and the number of users). Please consider firewalls too! Traffic to unknown ports maybe denied due to firewall policies of provider or local wifi. So if you really need realtime connectivity I guess you have to use sockets.