Skip to content
EN

Back to the catalog

andrewking.ca
rss2American English

iOS Development Archives - Andrew King

Andrew King · andrewking.ca · American English

rss2 wordpress content slash wfw atom dc sy

Open the feed

https://andrewking.ca/category/ios-development/feed/

Last post
Apr 28, 2020
Posts in 24 h · 7 days · 30 days
0 · 0 · 0
Our last check
Answering
Served from
United States
Site title
Andrew King
Text score at discovery
8,377
Format
rss2
Features in the feed
content, slash, wfw, atom, dc, sy
Community
wordpress

Posts

What our queue read from this feed. Open one to read it here, or go to the site that published it.

  1. How to Enable Custom Debugging in Release Builds
    Apr 28, 2020 · original
    Reliably enable debugging features for yourself. Hide them from your end users. Stop using #if DEBUG. TLDR: Use a custom Profile that includes a certificate. Install that on devices you want to enable debugging on. By detecting if that profile has been installed on the user’s device, you can enable/disable debug features that are impossible for your users to find. At my work we use TestFlight to distribute beta builds for internal and external testing. This a great, because once you certify a build as “ready for production”, you can just release it – it’s the exact binary that you’re going to ship. But there’s a problem – we also want to give ourselves some extra debugging controls in our TestFlight builds for things like switching to a staging environment, toggling feature flags, and viewing extra error info. These are features that we can’t ship to end users, but that we want available
  2. Using a Swift PropertyWrapper to ensure a closure is only called once
    Feb 27, 2020 · original
    Learn : how to write a property wrapper that avoids boilerplate for your asynchronous callback code. The Solution Code Want to skip to the answer? Variables marked with this property wrapper will be destroyed after they are read once. Use with caution! @propertyWrapper struct ReadableOnceT { var wrappedValue: T? { mutating get { defer { self._value = nil } return self._value } set { self._value = newValue } } private var _value: T? = nil } Now lets see how we got here. Avoiding multiple invocations of a completion block Let’s say we have a class that does some work, and then invokes its completion block. class NumberChecker { private var completion: ((Error?) - Void) init(completion: @escaping ((Error?) - Void)) { self.completion = completion } public func check() { if someCondition { handleFailure(NSError(domain: "MyDomain", code: 1)) } handleSuccess() } private func handleSuccess() { s
  3. When is it *good* for your App to crash?
    Feb 18, 2020 · original
    Most of the time, a crashing app is the very last thing you want. Obviously. But sometimes you really do want your app to crash to enforce correct usage of your APIs. What’s worse than a crash? Crashes are obviously bad – it’s disruptive to your user, they might lose data or work in progress, it makes them feel frustrated and less likely to open your app again, and it just smells like bad quality. But there’s something worse than a crash: undefined behaviour . Our programs are carefully thought through, and crafted so that the right input data is manipulated, used for calculations, stored, outputted, and otherwise trusted . But this also makes them brittle. Whether you realize it or not, all of these complex behaviours only work when you constrain your code to be used with some predefined, known range of inputs. When your code is given unexpected types of data, you can’t control what wil
  4. Why Agile-at-Scale is So Painful for Developers
    Feb 4, 2020 · original
    Does you use the Agile methodology at work? What do you think of it? Do you think it helps you be more productive? I suspect your answer to that question depends on a number of factors, but the key determiners are likely the role assigned to you by the Agile framework, and the details of how Agile has been adopted by your company. Why Agile is Supposedly Better Than Waterfall Waterfall has a fatal flaw – although thorough planning and a long-term roadmap are useful in organizing a coherent project plan and achieving a big goal, you’re stuck with this plan once you’ve started. Projects planned with waterfall will often do huge portions of their work before they are able to grab the separate pieces of a system and try them out together. This means that if something is wrong, you don’t find out for a long time – possibly until its too late. And if the market changes while you’re working on
  5. How to do High-Bar Code Review Without Being a Jerk
    Jan 25, 2020 · original
    How to do code review that enforces high standards while avoiding common problems on your team . Code review is the hardest part of being a developer. Seriously. Whereas most of our work is between you and a computer – a machine you just have to operate correctly and indicate clear intentions to – code review is a thing between humans. And like it or not, those humans are squishy, opinionated, emotional creatures. And those traits make code review a challenge. In principle your goal in a code review is simple: examine another person’s code and make sure their pull request (“PR”) is “good enough” to merge. But in reality there are a gazillion other things swirling around in your brain. Urgency – is this a hot fix for a major production outage? Seniority – am I allowed to decline this senior developer’s PR? Reaction – will someone yell at me if I decline this PR? Grudges – will you decline
  6. Clean Architecture – SOLID Design Principles Summary
    Apr 7, 2018 · original
    Clean Architecture is a book by “Uncle Bob” Robert Martin as a followup to his popular Clean Code . It includes a brief section about the SOLID principles, which are the touchstone of his programming philosophies, and have been described in his other books. This summary is a cheatsheet to help you remember the SOLID principles in your day-to-day work. The SOLID Principles Single Responsibility – each module should only have one reason to change Open-Closed – Design software so its behaviour can change by adding code – not changing the existing code. Liskov – Use interfaces/protocols to separate interchangeable parts Interface Segregation – Dont depend on things you don’t use Dependency Inversion – High-level code shouldn’t depend on low-level implementation The post Clean Architecture – SOLID Design Principles Summary appeared first on Andrew King .
  7. Auto Increment Build Number in Xcode
    Mar 31, 2014 · original
    This is a great Copy-Paste solution for every solo iOS Developer. It automatically increases the build number of your Xcode project every time you Run your program. Two Facts: You now have a reason to have a build number. You will spend less than a minute on this. And never worry about it again. Go to your Project’s Build Phases tab, and click the + button. Choose New Run Script Build Phase then drag the Phase to be second (after Target Dependencies). In the space after the shell’s /bin/bash , copy this: code#!/bin/bash bN=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE") bN=$((0x$bN)) bN=$(($bN + 1)) bN=$(printf "%X" $bN) /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bN" "$INFOPLIST_FILE"/code Works like a charm. Just make sure your build number starts as “1″ and not “1.0″. This great solution was originally posted by RobertL on Stack Overflow but I liked it so

Discovered by the rss-feed-index crawler, which checks each feed at most once a month.

Same record as JSON: https://api.agentalog.com/api/feeds/fd_andrewking_ca_8b357a577dee72e7. More from this site: andrewking.ca in the Feeds tab.