Naked Networking, SwiftUI and the game plan

Ok, so you just read the previous two articles on Naked Networking, if you missed them, here are some links.

Naked Networking with SwiftUI
More Naked Networking, more SwiftUI

The plan for this article then. In the first I outlined how to setup a listener for UDP packets, in the second we setup a transmitter to send UDP packets, both interfaced using the new SwiftUI framework. This time we’re going to be modifying our program to build a game. The game I have in mind ping pong, using two iOS devices.


We’re going to start with the network framework changes first, of which there are almost none. We need to add just one more method to our class.

This a simple routine to shutdown the listening interface on demand. In our game; it will, by default listen to port 1984; giving the option to close down that daemon, and bring up one listening to 4819. The idea is that idevice A will listen on 1984 and idevice B on 4819. They will send packets to their peer ports. So idevice 1984 will send a ping to 4819. And idevice 4819 will send a pong to 1984.


Most of the changes are in the ContentView.swift file. Firstly we need to define a new class that we will associate with a toggle we will add to choose which side your on either 1984 or 4819. We’re also going to give our players names. We’ll call 1984 “ying” and 4819 “yang”.

What does this code do. It is simple struct that is nothing more than a bool which will be managed by a iOS toggle. Should it true then you’re listening on 1984, transmitting on 4891. Should it be false than you’re listening on 4891 and transmitting on 1984. We also set the label on the switch accordingly within it. If true, you must be “yang” if false you’re obviously “ying”. We set the score label to force a refresh, a hack really.

Next we need to change the code within the body of the view. At the top, before the Text(“\(globalVariable.score)”) we add a toggle and reference our new struct we just defined. The frame code just moves the toggle to center screen.

The .onAppear block remains unchanged, but we need to rewrite the code for the Button. I show the whole shebang for completeness.

What did we do. We added a simple test that looks at the value of the toggle and sends out the corresponding ping or pong on a need be basis. As we sent it out, we also flip the local label to reflect that fact we just ping/ponged.

Make the changes and have a go. If you’re yang and you press whack, the label on ying changes to ping. If your ying and you press whack the label on yang changes to pong.

Bon, but wait before we finish we made used a technique that I hinted was more of hack then a real solution. Lets revisit it and make one final tweek to make this app does that little bit better.

Return to your Connect.swift file and add the lines you see here in bold italic. You are using another new framework called Combine. In said frame work we are defining a message protocol that will contain no data, and never report an error, it is as the name suggests nothing more than a pingProtocol.

We ping our interface when we get data thru the networking interface.

Back in ContentView.swift we need to add the lines shown in bold italic. What are we doing- The refresh variable does just that refresh the display when it changes and the disable flag prevents you from pressing whack.

The idea quite simple. After you whack the ping back, you need to wait for it to come back to you before you can whack it again. You need to wait your turn.

Are you enjoying this; lets press on read the next naked networking article here.

Written by

Coding for 35+ years, enjoying using and learning Swift/iOS development. Writer @ Better Programming, @The StartUp, @Mac O’Clock, Level Up Coding & More

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store