Swift / Apple Development Chat

[DT]

I'm considering starting a more general development thread, everything outside of native iOS/Mac, different tech stacks, languages, frameworks, DB design, tools, maybe some light infrastructure/DEVOPS type talk, maybe actual project talk, like who/what/where are working on / past projects, etc. I don't want to distract from this thread since it seems a lot of dev folks are focused here - and don't want it just to be me yammering on in an empty room

 

[MEJHarrison]

I'm considering starting a more general development thread, everything outside of native iOS/Mac, different tech stacks, languages, frameworks, DB design, tools, maybe some light infrastructure/DEVOPS type talk, maybe actual project talk, like who/what/where are working on / past projects, etc. I don't want to distract from this thread since it seems a lot of dev folks are focused here - and don't want it just to be me yammering on in an empty room

At work: .NET, AWS
At home: Swift, SwiftUI, Unity (playing with my Quest 2)
Other: TDD & testing in general, good design

Those are my highlights.

 

[Nycturne]

I'm considering starting a more general development thread, everything outside of native iOS/Mac, different tech stacks, languages, frameworks, DB design, tools, maybe some light infrastructure/DEVOPS type talk, maybe actual project talk, like who/what/where are working on / past projects, etc. I don't want to distract from this thread since it seems a lot of dev folks are focused here - and don't want it just to be me yammering on in an empty room

I could always complain about React Native and Java. My C# experience is getting far too rusty these days.

But I figured since there are folks that came from The Other Place, an Apple-specific thread may (or may not) work. A more general development thread would probably get more traffic anyways.

On another front, I'm getting pretty close to pulling the trigger on getting this through a beta review and start pulling folks into a beta pool. Also getting the website + early marketing material + social media presence ready. I just wish the Mac app wasn't what feels like 2 weeks behind the iPhone/iPad app.

 

[DT]

But I figured since there are folks that came from The Other Place, an Apple-specific thread may (or may not) work. A more general development thread would probably get more traffic anyways.

Whatever you'd like, I just didn't want to pollute your thread with off-topic development chit chat, but if you're OK with the intrusion, that's cool too.

 

[MEJHarrison]

Makes no difference to me. I'm not bothered with more posts in this thread.

 

[DT]

Side note: the little G walked in when I was posting above - she was like, "OMG, that's Persona 5!"

 

[Andropov]

Other: TDD & testing in general, good design

Learning TDD has been in my to-do list since forever. None of the companies I've worked for had tests as a core part of the development process, and I just didn't bother with my own apps. Weirdly enough, despite having zero tests, some companies relied heavily in architectures whose primary benefit was... ease of testing (I'm thinking VIPER). Even at the cost of massive amounts of boilerplate. For one of the latest projects I worked at, the client enforced a strict VIPER architecture + Protocol Oriented Programming + mandatory use of Publishers (instead of delegation) to 'talk' between architecture layers. I SWEAR 80% of the project was just boilerplate. Adding a single new screen required ~15 new project files. And yet: no tests.

Thankfully, I no longer have to work in that project (yay!). And I've been told we'll soon have a new team lead which has strong skills in TDD, so I may learn soon

On the architecture front though, sometimes I feel like a lot of people are just drinking the kool-aid. I thought maybe that'd change after I acquired more experience, but my opinion has only changed for the worse. For my own apps, I've been using MVVM since I started with SwiftUI (MVC for my old UIKit apps). And while I've run into problems I have to work on (massive ViewModel), it's far less tedious than prematurely abstracting everything in case ever want to reuse it (but with no intention on doing so).

At home: Swift, SwiftUI, Unity (playing with my Quest 2)

Ooh it's been a while since I last touched Unity. I've been participating on a game jam every summer for the last 2 years, but other than that, I haven't done much lately.

I could always complain about React Native

I do always complain about React Native. Tried it once for a couple days, and it was enough to keep me complaining for the next several years.

On another front, I'm getting pretty close to pulling the trigger on getting this through a beta review and start pulling folks into a beta pool. Also getting the website + early marketing material + social media presence ready. I just wish the Mac app wasn't what feels like 2 weeks behind the iPhone/iPad app.

Good luck!

Makes no difference to me. I'm not bothered with more posts in this thread.

+1

 

[DT]

I could always complain about React Native and Java.

I had a project I started in iOS native, Swift, coming from a previous project in Obj-C I [though I] had a decent handle on XCode though it had been years, with an S, since my last XCode work, realized it was unnecessarily complex given the nature of the project (and in discussing Enterprise iOS management with the client, I got some glazed over looks ...).

I'd wanted to try React Native (I had plinked around in React for web) to see if it allowed for quicker design iteration (since I do a significant amount of web dev so the layout approach looked familiar), and with this app, it's mostly just UI (so to speak), it's a pretty simple presentment layer, it does deal with the camera, but the data, the code logic, etc., is all in the API.

It also allowed me to address (with the client) there being an easy path to Android (while almost for sure, it still wasn't 100% given the target devices would be iOS based). Spent a few months in React Native, early on added Expo to the the toolchain because I needed several things in that SDK - even then I ran into a few needs that would've required an eject to native, but eventually the SDK updated, added what I needed, but then the tools would break, libraries go out of compatibility, etc., it was like herding cats.

This particular project was for internal use only, so I didn't need to deal with the App Store, and with React + Expo I considered just requiring an Expo client for consumption, so I could stay out of the native workflow altogether.

Then, mobile got back-burnered, we focused on the web side - for a long time - like a year When I came back to React, everything was busted. And I don't use React for my web development (in fact, I avoid most "heavy" JS frameworks), so it's not like I had been working around the technology in the interim and could just hop right back into it.

So sitting down and thinking about what I needed, what I had already (like a mobile friendly BS4 layout already in place), and not needing features like push notifications, I wound up knocking out a quick PWA as a POC (for myself). A manifest and a worker JS file and I had an app I could save in Safari that provided offline caching, and with a couple of network detect libs and a little local storage, I had a functional offline implementation for the one functional area that needs it. So I'm about 99% confident that when - which could wind up being if - I make it back to the mobile part of this effort, I'll just go PWA.

Short version: turns out it wasn't a nail, so I didn't need a hammer

 

[Nycturne]

it was like herding cats.

This is a good description of my experience. I jumped into an existing team and project using React Native. But the point of having a mobile client was to access the platform APIs in a way that the browser couldn’t. So it was a patchwork of orphaned/outdated dependencies and native modules, growing tech debt, and not enough resources to pay off enough of it to reduce the burden it was imposing.

I’m not against React Native in principle. But I think it’s being sold as a “use this to build a native, multi-platform app” to some teams, and they aren’t reading the fine print and understanding the limitations/costs they would be taking on doing so, and treat it like something that it isn’t.

 

[MEJHarrison]

Learning TDD has been in my to-do list since forever. None of the companies I've worked for had tests as a core part of the development process, and I just didn't bother with my own apps.

That's sort of my position. So the last time I did a SwiftUI project (2 years ago?), I also took that opportunity to try out TDD. It helps that I'm a weirdo who actually loves writing tests.

One thing that's caught my attention lately is just testing the public interface. As long as my code does the right thing and passes the tests, does it really matter how it arrives at those results internally? So you only test behaviors available through the public API and don't test private methods.

Testing is a surprisingly complex topic and at times an art form.

Thankfully, I no longer have to work in that project (yay!). And I've been told we'll soon have a new team lead which has strong skills in TDD, so I may learn soon

I'm trying to be that guy on our team. The problem is they just keep shoveling work at us so quickly, we don't have the time usually to slow down and do testing.

On the architecture front though, sometimes I feel like a lot of people are just drinking the kool-aid. I thought maybe that'd change after I acquired more experience, but my opinion has only changed for the worse. For my own apps, I've been using MVVM since I started with SwiftUI (MVC for my old UIKit apps). And while I've run into problems I have to work on (massive ViewModel), it's far less tedious than prematurely abstracting everything in case ever want to reuse it (but with no intention on doing so).

That abstraction is super important in the testing world. The tighter your code is coupled together, the harder it is to test. With interfaces, you can just give it something that resembles the real thing, but is just a bunch of fake code. So if you're testing Thing A, and Thing A depends on Thing B, by giving it a fake Thing B, it allows you to test Thing A in isolation. Then you can give Thing A a real Thing B and do integration tests. If you have a new team lead who's into TDD, you might get used to the idea of using interfaces.

Ooh it's been a while since I last touched Unity. I've been participating on a game jam every summer for the last 2 years, but other than that, I haven't done much lately.

I've not played with it a ton. But moving from an entry-level iMac to a Mac Studio will hopefully be a different experience. I'd still love to dive in there and play around some more. I just wish they full development experience was available on a Mac. But at this point, we can't preview things like Windows people. Every change you want to test needs to be built and deployed to the headset. Not the end of the world, but it would be great to skip the deployment every damn time.

I do always complain about React Native. Tried it once for a couple days, and it was enough to keep me complaining for the next several years.

I don't care for React Native either. But probably for different reasons. I do this stuff as a hobby (I'm a web developer by day). I have no real need to have my code work on both iOS and Android. So there's no reason to pick a tool that can do both. I did once (with Native Script), just to try it out. I wasn't a fan. I'm not looking to take the skills I already have and start writing mobile apps. I'd rather learn to do that stuff the correct way, and for me that's going full native. I'll admit those tools might make good business sense, but I'm not running a business. So I have the luxury of ignoring that crap.

The other problem I had (at least with Native Script 3-4 years back) is that the bare minimum app looked like it was just running in a giant web control, and it probably was. So extra work would have been needed just to have the out-of-the-box look and feel actually look and feel like an iOS app. I found that super annoying.

 

[Andropov]

That abstraction is super important in the testing world. The tighter your code is coupled together, the harder it is to test. With interfaces, you can just give it something that resembles the real thing, but is just a bunch of fake code. So if you're testing Thing A, and Thing A depends on Thing B, by giving it a fake Thing B, it allows you to test Thing A in isolation. Then you can give Thing A a real Thing B and do integration tests. If you have a new team lead who's into TDD, you might get used to the idea of using interfaces.

I get why it's testable. But combined with an architecture as obnoxious as VIPER, having everything be a protocol meant adding ever more boilerplate. For reference, VIPER architecture looks like this (for every single view you want to add):

I don't know how to convey this without writing an absurdly long post. Quick version: yeah, having FooView, FooPresenter and FooInteractor conform to FooViewProtocol, FooPresenterProtocol and FooInteractorProtocol makes each one of them very easy to be tested. But does it make sense testing, for example, FooPresenter in isolation? In my opinion, no.

I found an example of a short app to demo testing a VIPER based project. Here you can see the implementation of one of the Presenters in the project, SearchTrainPresenter. You can see that basically all methods in the protocol are limited to one liners calling other layers of the architecture. That is, in my experience, the way most Presenters work when implementing VIPER in Swift. So how do the tests for the presenter look like? Well, here is their test file. Essentially, it only tests whether the presenter has called the other layers of the architecture (Interactor/View). This looks like pure madness to me. How could this test ever be meaningful? How could it be cost effective? Genuinely asking.

And, while I know it's anecdotal evidence: none of the places where I've seen VIPER used had tests. At all.

One thing that's caught my attention lately is just testing the public interface. As long as my code does the right thing and passes the tests, does it really matter how it arrives at those results internally? So you only test behaviors available through the public API and don't test private methods.

Testing is a surprisingly complex topic and at times an art form.

I'm trying to be that guy on our team. The problem is they just keep shoveling work at us so quickly, we don't have the time usually to slow down and do testing.

I think I might add tests to my app after I finish the feature I'm currently working on (couple months, I hope). I don't know if it will help me catch bugs before I sent the app to app review (I hope it does!) but it'll sure help me start decoupling some parts of the codebase that I want decoupled.

The app has been out long enough for me to break things between versions. Every time that happens, I try to think: Could I have avoided that with a test? How? So I already have a good idea of how do I want the tests to look.

I'd rather learn to do that stuff the correct way, and for me that's going full native. I'll admit those tools might make good business sense, but I'm not running a business. So I have the luxury of ignoring that crap.

The other problem I had (at least with Native Script 3-4 years back) is that the bare minimum app looked like it was just running in a giant web control, and it probably was. So extra work would have been needed just to have the out-of-the-box look and feel actually look and feel like an iOS app. I found that super annoying.

Yeah, that seems like the experience I had with React Native. Out of the box it provided an acceptable Android app and a mediocre iOS app (not bad!). But polishing the app further required so much extra work that I'd rather write two fully native apps. But I'll admit part of that was because I just found React difficult

 

[MEJHarrison]

And, while I know it's anecdotal evidence: none of the places where I've seen VIPER used had tests. At all.

It's frustrating at my job because we all know we should be writing tests, but in practice, it just doesn't happen.

I think I might add tests to my app after I finish the feature I'm currently working on (couple months, I hope). I don't know if it will help me catch bugs before I sent the app to app review (I hope it does!) but it'll sure help me start decoupling some parts of the codebase that I want decoupled.

The app has been out long enough for me to break things between versions. Every time that happens, I try to think: Could I have avoided that with a test? How? So I already have a good idea of how do I want the tests to look.

My experience when I tried TDD is that while I think I went overboard by testing literally every line of code I possibly could, it absolutely made life quicker and easier as time went on. Since I was also learning SwiftUI, I made quite a few bad design choices. The tests let me step back, re-write large chunks of code, and still have confidence that everything was working as expected. It was very freeing. It led to more experimentation since between tests and source control, I could go wild while still having a safety net. If I tried something and it was a disaster, I knew it instantly and could be back to stable code in seconds.

Testing is a lot like exercise. Everyone knows they should be doing it and that it will make them healthier and probably live longer. Yet so many people have a hard time just doing it.

 

[Nycturne]

Testing is a lot like exercise. Everyone knows they should be doing it and that it will make them healthier and probably live longer. Yet so many people have a hard time just doing it.

And much like exercise, the longer you go without doing it, the harder it is to get back into the habit.

 

[Citysnaps]

I'm considering starting a more general development thread, everything outside of native iOS/Mac, different tech stacks, languages, frameworks, DB design, tools, maybe some light infrastructure/DEVOPS type talk, maybe actual project talk, like who/what/where are working on / past projects, etc. I don't want to distract from this thread since it seems a lot of dev folks are focused here - and don't want it just to be me yammering on in an empty room

Hardware, too? Or just software?

 

[DT]

Hardware, too? Or just software?

Firstly, I think the consensus was to just sort of broaden the scope of this thread a bit and include development topics outside the scope of the title.

Either way, here or a new thread, I'm sure everyone would appreciate some hardware talk, you know, relating to development (vs. like a "build thread" for Winders™ PeeCees ...) Like Raspberry Pi running custom apps and sensors for a DIY garage door opener, etc.

 

[Nycturne]

One thing that's caught my attention lately is just testing the public interface. As long as my code does the right thing and passes the tests, does it really matter how it arrives at those results internally? So you only test behaviors available through the public API and don't test private methods.

Back on the testing topic, this caught my eye. I’ve always tested this way for two reasons:

1) Getting into private methods is always a right pain.
2) Code coverage tools can be useful not just to show you what code you aren’t exercising, but also what code might be unreachable via public methods. And if it is unreachable, then perhaps you can cull it.

I finally got to cull around 1k LOC this evening after a big refactor to align my MVVM design closer to the ideal. Deleting code sometimes feels just as good as writing it.

Also learned a few tricks for using Combine effectively to avoid data dependency snarls in some trickier portions of the code, and realizing that a Combine publisher or subscriber is a pretty good interface for testing. Not a bad evening.

That abstraction is super important in the testing world. The tighter your code is coupled together, the harder it is to test. With interfaces, you can just give it something that resembles the real thing, but is just a bunch of fake code. So if you're testing Thing A, and Thing A depends on Thing B, by giving it a fake Thing B, it allows you to test Thing A in isolation. Then you can give Thing A a real Thing B and do integration tests. If you have a new team lead who's into TDD, you might get used to the idea of using interfaces.

Apple had a talk not long ago about Protocol Oriented Programming. Where you define the protocol first, and even use extensions of the protocol to share code between implementers rather than base classes. I like the idea because shared code that lives with the protocol is pretty easy to test when the interface is already clearly defined.

I’ve tried to follow it, but I’ve not been super great at it. With this refactor I’m planning on making another attempt as a way to compose view models, as I identify targets for further refactoring and patterns emerging between the different view models.

Firstly, I think the consensus was to just sort of broaden the scope of this thread a bit and include development topics outside the scope of the title.

Either way, here or a new thread, I'm sure everyone would appreciate some hardware talk, you know, relating to development (vs. like a "build thread" for Winders™ PeeCees ...) Like Raspberry Pi running custom apps and sensors for a DIY garage door opener, etc.

Could always combine the two and talk about Swift on the Raspberry Pi.

And yes, I have a couple Swift on Linux projects, including a YAML-driven aquarium light controller that lives on a Pi.

 

[Andropov]

Apple had a talk not long ago about Protocol Oriented Programming. Where you define the protocol first, and even use extensions of the protocol to share code between implementers rather than base classes. I like the idea because shared code that lives with the protocol is pretty easy to test when the interface is already clearly defined.

I’ve tried to follow it, but I’ve not been super great at it. With this refactor I’m planning on making another attempt as a way to compose view models, as I identify targets for further refactoring and patterns emerging between the different view models.

How long ago is not long ago? I've tried to search for it but I only found one from WWDC '15.

 

[Nycturne]

How long ago is not long ago? I've tried to search for it but I only found one from WWDC '15.

Further back than I thought apparently. Geez, the talk was 7 years ago?

 

[DT]

This is a good description of my experience. I jumped into an existing team and project using React Native. But the point of having a mobile client was to access the platform APIs in a way that the browser couldn’t. So it was a patchwork of orphaned/outdated dependencies and native modules, growing tech debt, and not enough resources to pay off enough of it to reduce the burden it was imposing.

I’m not against React Native in principle. But I think it’s being sold as a “use this to build a native, multi-platform app” to some teams, and they aren’t reading the fine print and understanding the limitations/costs they would be taking on doing so, and treat it like something that it isn’t.

The dependency management was such a chore, and then - since I saw right up front RN out-of-the-box lacked support for a few things - I wound up using Expo, so I've got frameworks on top of abstraction layers, with hopefully some working native at some point. Good luck

Seriously, I think it's probably a good fit with one or more of the following cases for your App:

Will be cross-platform
Doesn't need the highest possible performance
Doesn't require specific hardware / OS services
You have existing React and/or JS skill resources

It's also seems to be a good fit for rapid prototyping, and if you use Expo, you can push immediate updates to your team/client - or for that matter, if you're using only React Native /Expo, so you're never dealing with the native code (like for an internal app that doesn't need to go through the normal distribution/validation mechanisms).

 

[Nycturne]

Yup, this aligns a lot with my own thinking. The problem is that the team I joined built it explicitly to access specific hardware/OS services. It was originally written by a team of web developers, so I’m not surprised, but oof.

One thing has come of this thread: I’ve been pushing code coverage numbers up on my own project. Since I just did a big refactor to clean things up, it was ripe for a bunch of tests. Also used the opportunity to leverage more of the Combine tricks I’ve been picking up. Since the project is starting to sneak up on the 20k LOC mark, cleaning it up while fixing bugs seems like a good idea. Should probably be firing off the first beta build (iOS only sadly, Mac still has a couple key things it needs to catch up on in the UI department) for review here in the next few days.