Swift is different from other languages. The same rules do not apply. Other languages can use reflection to alter your runtime code to mock out the classes. But you can’t do that in Swift.
iOS apps fail for a number of reasons other than simple logic errors that we typically catch with unit tests. The app may not install correctly, or there may be a problem when you move from landscape to portrait and back again.
Every quarter we at RIIS choose three apps that we add to our Research queue. We pick some emerging technology and then the interns and people on the bench get to turn the idea into a real app.
Continuous Integration (CI) systems really come into their own when working on larger projects with a team of developers. As each developer checks in their code, the app is built, unit tested and you even have the option of letting the business stakeholder get a copy of the app.
In this blog, we’re going to look at creating a simple app to show how easy it is to add unit testing to Swift apps in Xcode. We’ll look at how much we get out of the box and then create a calculator app to do some simple unit tests.
Swift was announced at the WWDC in 2014 and late last year the code was open sourced. It can run on both OSX and Ubuntu which is a huge departure for Apple which has typically been a more closed system. The language Swift is a completely different animal to Objective-C.
As you may or may not know, Android apps can be decompiled back into something very close to the original Java code. It’s a simple process. You don’t even need a phone. Download the target APK using the Apkpure website and then use Jadx to decompile the code back into Java.
When RIIS was just two guys and a laptop, we mostly worked on call center screens for small telephone companies. The work was all about pulling information from databases and APIs so that 90% of the customer information was presented intelligently on the first screen so a call center agent could get on and off the call in the quickest possible time.
On Android, an application must perform all non-UI computations on a background thread. In fact, the Android OS enforces this by displaying a “Application Not Responding” (ANR) dialog for applications that do too much on the UI thread, and are therefore not responsive to user actions.
It’s rare during your development career to have the luxury of being able to start with a clean slate every time you begin a new project. More often than not you’re going to have to extend code written by someone else.