Today, I want to present to you SwiftAlyzer, a tool to review Swift project’s, a tool to help refactoring and keeping it maintainable. As a software architect I find myself oftentimes reviewing projects. Either new projects that are taken over from other companies. Or monitoring the health of an ongoing in-house development. While every feature of a software can be well structured applying design patterns and code heuristics, it’s oftentimes the ensemble of all features to a whole app, that lacks a good structure. It’s where dependencies from one feature reach out to another and back and forth, that lead to an overall maintainance nightmare.
Every feature on its own can be quality-checked by looking at the source code, reviewing in so called pull requests to review its quality. It’s hard to get an overview of the inter-class dependencies when looking at source code solely. But often it’s these dependencies that ruin the maintainability slowly but steadily when not supervised.
Quick architecture review of Signal’s iOS App using SwiftAlyzer weiterlesen →
In April I talked about my newest projekt, SwiftAlyzer, a tool to analyze the quality of software projects written in the Swift programming language.
There’s now a clear milestone plan for the closed alpha and public beta releases. Right now, we’re heading for the alpha release and it looks pretty neat already. If you’re interested in joining the closed alpha programming, just drop me a line on Twitter pm or here: email@example.com
In the last few days worked on these little loading animation. I’ll shortly write a little tutorial on how to create this image layer masking effect.
Stay tuned ✌️
Making the best out of Corona-wise cancelled sports evenings, there was suddenly enough time to smartify my garade door. It already has connectors on the garage door hardware. That way, I could connect a button to the board that is used to open and close the garage. But what was missing is a way to control it remotely.
Since the remote went missing it was nearby to integrate the button into my smart home setup: Homematic actuators and a raspberry pie transferring all traffic via MQTT.
Almost 3 years ago I started a tool to analyse dependencies of Swift projects. For bigger projects it’s essential to plan dependencies between classes and among modules beforehand. Otherwise a project’s inter-dependencies grow wild and after a while, everything depends on everything.
Why that’s bad you might ask? Because then it’s impossible to replace a class with different functionality, since too many other depend on it. And thus, it gets harder to implement new features, adapt existing features and keep the bug count low.
So that’s planning, but what get’s implemented is another story. It’s easy to forget about planned dependencies while implementing and that’s even more true when working in teams of 5, 10 or more people. That’s where tools for visualizing dependencies come into play. Every now and then, one can use these tools to check the actual inter-dependencies of a project and compare them with the planned ones.
The existing tools all have one big shortcoming: They ignore ordering structures like modules. All classes are layed out in one space, which gets confusing when visualizing projects with more several hundreds classes:
Swift Dependency Analysis weiterlesen →
Recently I updated xcode on our CI server and additionally provide the option to use older xcode versions per project.
To verify that the option works I wanted to find out the iOS SDK version from the provided ipa.
Here we go:
Assuming the app is named APPNAME and the ipa my-app.ipa.
rename my-app.ipa to my-app.ipa.zip
unzip my-app.ipa.zip (Now we’ve got a folder named Payload)
execute the following bash command: otool -l Payload/APPNAME.app/APPNAME | fgrep --after-context=3 LC_VERSION_MIN_IPHONEOS
A working master branch in a continuous integration environment is key for fast development. While we hack line after line into the project, we merge back to master branch often even while the feature branch is still in development.
Merging early and often helps to avoid merge conflict hell because otherwise feature branches move too far apart. But this comes at the risk of breaking the master branch build. If that happens, the developer in charge has to stop his ongoing task and fix stuff immediately.
Until recently we used emails to notify the team of a failing build. But since email is old-fashioned, we hacked a signal light to show us the current build status. Follow the instructions below if you want to build your own Jenkins Traffic Light: