I am building a companion app for a board game that helps players make the necessary mathematical calculations needed to play the game. I was planning on making it so that phones running the app could just communicate via a local area netowork via TCP/IP. The app listens on a TCP/IP port for data coming from other phones on the local area network running the app, and sends data to other phones on the network running the same app. I was told that this type of networking would be problamatic when it comes to getting the app approved for distribution on the Apple App Store because of security risks. Would this type of networking face issues during the audit process and possibley not get approved?
Listen to TCP/IP port and App Store approval
Who told you this?
As long as this is a clearly stated feature of the game, it doesn't interfere with normal performance of the device, and isn't some back-door gambling or P2P file sharing system, it will be fine.
The "audit process" is basically this:
1) Does the app crash or hang immediately on launch? Does the app drain the battery by running in the background for 10 minutes?
2) Is the app an obvious scam?
3) Is the app a clever scam? Does the app seem to have technical features that don't match the marketing?
4) Is there any other violation of App Review guidelines or developer agreement?
If results of this audit are all "no", then the app is approved.
I'm in a group of CS students working on the app as part of a class. We are relatively inexperienced with mobile development so we asked for advice from a group member's co-worker who has developed some cross-platform mobile apps.
The game is similar to dungeons and dragons and requires some calculations with stats be done for each move. The app would just keep track of a player's stats and also display the stats of the other players so that their stats can be combined for some calculations. We had intended on on having each player initiate a connection with other players on a WiFi network, listen to a TCP/IP socket for updates from other players, and send updates to other players via the TCP/IP port the other player's app is listening on.
We were told that this is not the traditional way to use TCP/IP and we should instead have all clients/players send and receive updates by sending requests to a webserver. We were also advised that listening to a TCP/IP port would make the phones vulnerable to attack.
My response was more directed towards the app review side of the question.
As far as networking goes, I would half-agree with your advice. Or maybe 0.25 agree. You wouldn't want every device to connect to every other device. The number of connections and bandwidth required would grow exponentially. Normally, all devices send updates to one server. That server then sends regular updates to all devices. This way, each device only needs one connection to a central device. This routing of messages is relatively easy and doesn't impose much of a performance burden. It can run on one device even while that device is playing the same game itself.
That central device does not need to be a webserver, although it can be. You could implement this in low-level TCP/IP. Then again, you could implement it in websockets much more easily. But it can, and should, be something embedded into the app, not a standalone webserver. I'm not a game developer. There could be other specific technologies that game developers typically use. I have taught a university class and setup a simple game-like 3D rendering example as a way to demonstrate client/server networking. In that example, I actually was using the built-in webserver on my Mac and allowing the students to control the 3D display via websockets. They just had to code up the client side Javascript in class if they wanted to connect. 🙂
I wouldn't worry about any security vulnerabilities. It is not like your app would be installed on 100 million devices. If your networking was really low-level and poorly done, then it might be possible to hack it. But iOS itself is quite secure so they wouldn't get anything beyond your app's own sandbox.
What john daniel said plus…
iOS does not have built-in APIs for running an HTTP server. You can use an external library for this [1] but, as you don’t actually need an HTTP server, you might want to choose something simpler. john daniel’s suggesting of WebSocket is a great idea, especially now that iOS 13 has built-in support for both WebSocket client and server (yay!).
With regards on-the-wire security, if you’re using the built-in WebSocket support then you can take advantage of Network framework’s support for TLS pre-shared key. The WWDC networking sessions this year [2] included a great example of how to put these bits together.
One final thing to watch out for: When your app moves to the background, iOS will typically suspend it, which means you won’t be able to respond to network requests. The plan that you and john daniel have been discussing so far will work just fine as long as the app stays in the foreground. If you need to also work in the background, things get more complex.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"[1] If I were doing that, I’d look to the various Swift on server facilities available via Swift Package Manager.
[2] Specifically:
WWDC 2019 Session 712 Advances in Networking, Part 1
WWDC 2019 Session 713 Advances in Networking, Part 2