This weekend I wanted to setup Precompiled Bridging Headers for my project. This setting is available in the new Xcode 8.3 beta. Then building for latest official XCode (8.2.1) the code will not compile because the Swift compiler doesn’t recognize it. How do we use different build settings for different Xcode versions? Only possible with xcconfig files.
There’s an undocumented build setting called XCODE_VERSION_MINOR that we can use here. And after some variable substitution we’ll make it work. Here’s the gist:
// Setting for last Xcode
OTHER_SWIFT_FLAGS_XCODE_0820= //<previous flags, if any>
// Setting for Xcode Beta
// Switch configuration based on Xcode version
There’s times when you need to investigate regressions in your project, and you don’t know have any clue as why something is happening. Git bisect is the best tool for this cases, but it can be painful to use in non small projects using CocoaPods and Xcode. I want to share what I’ve been doing to ease the pain.
Have you encountered this error when upgrading to the latest CocoaPods (1.1.0), or sharing a library between your iOS App and your extension?
'sharedApplication' is unavailable: not available on iOS (App Extension) - Use view controller based solutions where appropriate instead.
If yes, continue reading, as you might have encountered same issue as myself. I’ve recently had to upgrade a project to using Cocoapods 1.1.0. Things stopped compiling, and I had to investigate the root cause of the problem. It has to do with iOS App extensions, unavailable APIs and how fragile our tooling is ;).
Last thursday I gave a talk at NSLondon meetup called ‘Minimum Viable Tooling’. The topic was examples of approaching tooling and automation for small teams. I showed real examples of what we do at Peak, where I currently work. One of the things people showed interest in after the talk was how we deal with localizations.
In this post I will replicate the simple solution from scratch, so you can follow along and get started with your own projects. And we will be using Swift for the scripting, just because we can!
Much of the literature and writing related to sofware development focuses on the creation, new ideas, fresh ideas and things to improve in your next project. But when is it a good moment to delete the old stuff in an long term project? Here’s my short rant about this; I recently deleted a chunk of code in my current project and just felt I wanted to write my thoughts.
The latest xcode beta is available for downloading. There are many improvements, and the usual problems with stuff that stops working… Ah the love of Apple for it’s developers :). But I want to tell you about a feature that caught my attention: New analyzer settings!
The static analyzer warns when nil is returned from a method or function with a nonnull return
type or is passed to a parameter marked nonnull.
The static analyzer checks for common misuses of Objective-C generics.
The static analyzer checks for missing localizability. This check is off by default and can be
enabled by selecting ‘Yes’ for ‘Missing localizability’ in the ‘Static Analyzer - Generic Issues’ build
There are 3 new settings related to these new features: CLANG_ANALYZER_NONNULL, CLANG_ANALYZER_OBJC_GENERICS and CLANG_ANALYZER_LOCALIZABILITY.
CLANG_ANALYZER_NONNULL and CLANG_ANALYZER_OBJC_GENERICS
Objective-C continues to get some love! Adding into the changes for nullability and generics, now the analyzer will start to warn you about usage not in line with your annotations. That’s very good news, considering that the compiler checks were a bit lacking. Additional kudos because both settings are enabled by default.
This is an intriguing one. Let’s investigate further; Let’s say you have some code where you set a string to a label:
You’ll now get a nice analyzer warning: “User-facing text should use localized string macro”
But you won’t get a warning when the key is not localized. Like:
Having worked in companies developing their own products, I’ve faced many times the problem developers encounter when building iOS applications: Your biggest 3rd party dependency - the OS SDK - is changing under you every year. How does your team deal with this in a maintainable way?
Swift is finally open source! This is great because of many reasons, namely the transparency and chances to learn from the people responsible of building the foundational language you work on. I’ve been checking how easy was to build the runtime, REPL and compiler, and it turns out the team made an excellent job to make the process very easy. Let’s see how to do it.
‘Know your key shortcuts’ is the mantra of the productive programmer. I’ve chosen to try using the same keybindings everywhere, investing time and learning Vim. And using xvim in Xcode. In this article I’m going to try to explain why I did this, and I’ll share my experience of the process.
In a previous post, I wrote about the choice of paradigms that Swift presents for it’s target audience. I also gave my opinion on how people with different backgrounds might see and approach the Functional Programming paradigm.
In this post I want to share how I started to take advantage of FP with Swift for the practical domain of iOS developers: Building apps.
It’s a very exciting time to be an iOS or Mac developer. The platform moves very fast and we got a new toy (language) to play with: Swift. It’s the perfect time to reevaluate, learn and evolve as a programmer, because you will be forced to adopt this new language (yes, I think Swift is the future, 100%).
I want to relate this to the fact that most iOS engineers, or mobile application developers, are traditionally familiar with Object Oriented Programming paradigm. But Swift offers more than different syntax and OOP.
I’m referring to some features inspired by functional languages. If you’ve ever had an interest, but never the chance or motivation to go forth and look into this paradigm, now it’s the perfect time to do it.
Yesterday my last post on the series ‘Let’s build Freehand Drawing for iOS’ has been published at Badoo Tech blog. It’s been a very good experience for me, and of course I recommend you visit the tutorials if you are interested.
I divided the tutorials in 3 parts:
Part 1: Introduces the feature and a naive implementation
Part 2: Adds undo functionality, refactoring along the way
This series has been my first take on writing technical tutorials. And I must say that it’s a lot harder than I thought. You need to keep track of the content, code correctness, and the pace of the articles so it’s readable and understandable. Coding while writing an article is challenging, but the experience has been very gratifying.
I also get to brag about something I was really happy to build for the Bumble project. So I think I’ll definitely write other tutorials in the future.
This year in WWDC, Apple introduced Objective-C ‘lightweight’ generics for XCode7. This builds upon the improvements to Objective-C to document the code and improve the interoperability with Swift. I wrote previously about nullability annotations and I continue to be delighted by these changes to the language. Here’s what I think.
As an iOS developer or Apple-centric developer, WWDC is a time of excitement and news. The yearly event at Apple offers many networking opportunities, but most importantly sets the stage for the next year of development in the company’s platform. As this year event is closing in, I wanted to write my thoughts on a related, and often overlooked topic; fragmentation
Apple introduced nullability annotations to Objective-C compiler from XCode 6.3. I was really surprised by this change, and welcomed it with open arms when I saw the release notes. My first thought was: Objective-C is learning from Swift! I want to share my 2 cents on this new annotation and what it means for more modern Objective-C code.
I wrote a while ago a tip, mostly for my future reference, how to set up a HDD with Raspberry Pi formatted using exFat. After more intensive testing on my Samba setup, I’ve decided to go back to NTFS as my format of choice.
A few days ago I switched my HDD on my Raspberry Pi to a SSD drive. I use the Pi as a NAS serving files at home and I wanted to use a HDD for music with less storage but more reliability. This drive runs 24/7. I also chose exFat for the filesystem. I write this as a future self-reference, but may be useful for somebody else, so here it goes.
Write code, compile, wait, navigate to screen in application. Fix problem, recompile wait. Oh it was not fixed, start again… Does it sound familiar? For compiled languages there seems to be no workaround this bottleneck. Even though this is true, there are situations where we can reduce the waiting time, increasing our productivity and happiness. Enter code injection.
Whenever I meet some developer, I can always get a really interesting conversation. Be it tools, opinions on platforms, favorite blogs, books, or
some new technique I didn’t know about.
That’s why it’s important to discuss with other people in the field their opinions, they challenge your assumptions and you can gain useful
insights which otherwise would be hidden to you for longer. But sometimes, you hit a wall. Somebody does not listen.
Let me confess: I always loved smart watches. I am a geek and I like gadgets, I love to see new features ‘just because they are cool’. I own a Pebble watch and I love it, and I most probably will buy Apple Watch. But I think Apple did not solve the main issue with today’s mobile technology, and Smart watches in particular.