View profile

 iOS Code Review | Curated code improvement tips - Issue #18

 iOS Code Review
 iOS Code Review
@ios_code_review
Hi there,
I hope you enjoy today’s content. Let’s dive in 👇

Documenting app's footprint
Here’s an interesting thread where people share how they document where the app saves things and how they like to organise constants. Lots of opinions - some prefer enums, others prefer extensions on UserDefaults. I personally like to use enums as shown in this tweet - making one per-app or per-module depending on the size of the codebase.
Marina Gornostaeva ✨
Usually I want to have a clear overview of where my app stores stuff. For me, the best documentation is the code itself.

So I gather the constants in one place - for user defaults, keychain, disk, etc. I like to call it `AppFootprint`.

How do you prefer to document this? https://t.co/BC6G9a3e9y
Named loops
If you have nested loops, you can label them, and use the label as part of your break or continue statements. This also works for if, switch, do statements. Here’s an article with more detailed examples: Swift’s Break and Continue Statements by Andy Bargh
Manuel Schulze
💡 You can give Swift loops a name (as you can see below).

This can become handy when you want to break out of an outer loop. You don’t need to keep track of your own variable and add some additional if-statements.
#iOSDev #SwiftLang https://t.co/IsAJchyp60
Text or String?
If you also get tired of wrapping strings in Text all the time, here’s a tiny extension to make it easier:
Blaz
A lot of times I pass "String" to some #SwiftUI component but Text() component is required. Here is my solution to this. #swift #iOS #swiftlang #swift https://t.co/kin36VZi9H
Some wise words
I concur:
Matt Diephouse
Programming:

1. Move build settings to a shared file

Engineering:

1. Write script to record resolved build settings
2. Move build settings to a shared file
3. Diff resolved build settings to verify they didn’t change
On passing App Store review
This one is not about improving the code, but improving the release cycle of the app. In this thread @jordibruin shares how he organises his App Store review submissions to minimise chances of getting rejected. Such wonderful advice that I couldn’t not share!
He explains what he writes in the messages, attachments he makes, and most interestingly about his FAQ page he shares with the review team.
Jordi Bruin
I’ve been doing daily updates for the last few days for both the iOS and macOS versions of Navi and wanted to share a bit about how I minimise the changes of getting caught in App Review

👇🧵 https://t.co/jOZ4UUk7SD
☮️
Alright, that’s it for today. 
Did you enjoy this issue? Let me know by pressing the buttons below, so I can improve the newsletter. 
Got feedback? Want to see more, or less of certain kinds of tips? I’d love to hear from you. Reply to this email or reach out on Twitter via @ios_code_review 🙌
Did you enjoy this issue? Yes No
 iOS Code Review
 iOS Code Review @ios_code_review

Bi-weekly newsletter amplifying code improvement tips from the Apple developer community in a bite-sized format. Swift, Objective-C, iOS, macOS, SwiftUI, UIKit and more. Curated by Marina Gornostaeva and published every other Thursday.

For feedback or sponsorship ->> [email protected]

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.