The conference started with awesome talks. WASM is an exciting ecosystem growing daily thanks to developers from many different programming languages like Swift, Rust, C++, Python, etc. For this event, Tyler McMullen opened the conference with a talk about WASM’s history, current state, and future outside of the browser. Covering technical details and community effects that make this not just viable but super valuable. And how it all ties together into a future that gives us the freedom to run code where and how we want to.

For our team, this talk was really interesting. WebAssembly is the technology our cross-platform team uses to be able to reuse the Swift code written for years to be able to make GoodNotes the best note-taking and PDF markup app. Thanks to WebAssembly, our team can reuse thousands of lines of code almost for free and focus on shipping the best possible product instead of duplicating a massive, already-written codebase.

This was just the beginning, and it was an amazing talk. Later this day talks like “Wasmer Things: An Upside-Down Guide to WebAssembly” by Edoardo Vacci or “Mobile app development with WebAssembly GC” by Vivek Sekhar completely got our attention. Low-level details related to how WASM works under the hood or WasmGC works were among the best. Digging deep down into the tech stack we use helps us identify improvement areas in our codebase to build a better product.

Vivek Sekhar’s lightning talk about WebAssembly GC was one of the best surprises this event gave us. If using WASM GC, we can improve our performance by efficiently supporting high-level managed languages to WebAssembly, via struct and array types that enable language compilers targeting Wasm to integrate with a garbage collector in the host VM be a really nice improvement for us.

Right after having lunch, another talk got our attention. This time because of the special mention to Yuta Saito! Yuta joined our team more than one year ago and contributed to our project with awesome technical improvements. We are lucky to have Yuta on our team and also glad to see how he’s also an important reference developer for other engineers.

The first day was about to end when we noticed there was an excellent lighting talk about to start! “Rust and WebAssembly threads on production: a field report” by Roberto Vidal. An amazing talk about how Roberto and the rest of the team built them, what they tried, what worked, and what is yet to work! As you may expect, WebAssembly threads unlock a game-changing primitive for the Web and other targets. Workloads that require shared memory and parallelization can finally leverage the full power of the underlying platform.

Ready for the second day, our team woke up willing to listen to awesome talks. Checking the agenda there were promising talks. From new toolchains to cloud computing or even blockchain!

There was a special talk we wanted to mention. If you work with WASM, you know what we are talking about. If you have never heard about WASM, the fact that we specially mention this talk may be shocking. “WebAssembly debugging demystified” by Nisanthan Nanthakumar. A thorough review of the DWARF debug file format and the tools available to be able to include breakpoints, evaluate expressions and inspect our code. Believe it or not, debugging WASM binaries while executing the binary on a browser was not straightforward for us. Since we started the project, the team has not been able to inspect variables or evaluate expressions with the tooling provided by standard browsers like Google Chrome. However, this talk gave us information about some tooling we can use to inspect the WASM binaries and check in detail the memory allocated.

Before ending the day and the conference, our front-end team decided to get out of their comfort zone and learn about something different and experimental for them: Grain and Lunatic. Lunatic is a runtime for building distributed, highly concurrent systems with WebAssembly, and Grain is a programming language that makes getting up and running with WebAssembly a breeze. This talk was about the ins and outs of Lunatic, from its process spawning model to how it can run untrusted code and ultimately build a full application that can withstand enormous amounts of traffic.

The event ended on Friday afternoon, and it was time to return home. We had an awesome time at WASM IO! Our team works remotely, and having the chance to see each other on-site in events like this is something we love. However, this is not it! After the conference, we have to check some details and some notes we took to see how we can improve our usage of this technology. This is a list of tools and projects we want to check in detail we’ve found interesting:

• Twiggy: A WASM binary size profiler.
• wasm-snip: Optimize the binary size by replacing unused functions with a nop version.
• wasm-gc: Promising Google Project we want to try as soon as it is available.
• Docker + WASM: Docker support for WASM.
• Javy: Running JS into WASM.
• WABT: Tooling to be able to work with wasm files.
• Kowasm: Fullstack development with Kotlin and WASM.

This article was written by:
Pedro, Mauro, Antonio, and Trujy part of the cross-platform team at GoodNotes.

GoodDevs at WASM IO 2023 was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why should I care about Mutation Testing?

Whenever we develop a program, we, as engineers, should always guarantee this software is working as expected and any future change we implement when adding some new features or updating any behaviour doesn’t break it. To be able to do this, we frequently use automated testing. Automated tests are our safety net and a guarantee of the correct behaviour of our program. Obviously, all of them run on CI and use many different testing strategies! Let’s take a look at the list of automated testing strategies we use at GoodNotes:

• Classic unit tests, including parametric ones.
• Integration tests for storage and network usage.
• HTTP stubbing.
• Contract tests for the API.
• Screenshot tests.
• UI tests mocking API integration.
• Property-based tests.
• End-to-end tests.
• etc

Up to this point, we may think having all these tests and using many different testing strategies is more than enough to ensure the quality of the project. However, how can we measure the quality of our tests? What tools can we use to ensure our safety net is safe enough and any future change breaking the app will be detected automatically? It’s time to use mutation testing!

Originally proposed by Richard Lipton et al in 1979, Mutation Analysis (AKA Mutation Testing) is an automated (or not) testing strategy we can use to check if our tests will help us and identify bugs when our software evolves over time. It can be a more pragmatic, complex, and interesting approach than just using code coverage or the number of tests as a quality metric. It can also be used as a forensic tool for our codebase.

The idea is simple. We first get a test suite passing, then we apply some random changes to our code, ensuring these are valid in build time, and last but not least, we run our tests again. If we don’t see our tests failing… we fail with them!

Build-time valid code mutations should make our tests fail unless these mutations are semantically equivalent to the original code, obviously! If we change our production code and the behaviour changes, we should get a test letting us know there is something we should check. Maybe it’s not a bug, but a behaviour we updated, so we should update our tests accordingly to ensure this new behaviour is covered.

Up to this point, you may be thinking this is too much for your app. And maybe right, but now think about payment systems’ software. How would you feel if I randomly change the software computing your payslip and tests are still passing? Critical paths like payments or health-related software are great candidates if we want to use mutation testing, but this testing strategy may not be so important for other elements where fault tolerance is cheaper.

Now that we know how this tool works, it’s time to review the list of mutations we can apply before executing our tests. Stryker, a well know mutation-testing tool got a list here.

Time to get your hands dirty!

Would you like to practice mutation testing? We’ve got you! We created an exercise for you. You can clone this repository and follow the exercise. In this repository, you’ll find a TypeScript module written already implementing a simplified version of a kata named “KataPotter”. You’ll only find the production code, so your goal is to write all the tests you want and then evaluate if the tests written are able to survive mutations. These are the rules the ``checkout`` function follows in order to check the cart prices for this kata:

These are the steps you have to follow in order to complete this exercise:

• git clone https://github.com/pedrovgs/typescriptkatas
• cd typescriptkatas
• git checkout practice-mutation-testing
• yarn install
• yarn test
• Write as many tests as you want and check code coverage: yarn test && open coverage/index.html
• yarn test:mutate && open reports/mutation/mutation.html

Once you get to this point, you’ll find that you have quite a high coverage (probably 100%) however when you evaluate your tests using mutation testing, you’ll find there are some mutations surviving!! In my case, I got 4 mutations surviving, 1 timeout, and 58 mutations killed!

This report from the mutation testing tool is just great. Stryker (the tool we are using) has found we can replace a “*” operator with a “/” operator in our code and nobody would notice!! How is this possible? Because there was a missing test scenario we didn’t include it!

What about other programming languages?

Would you like to use it tomorrow in your projects? Here we got a list of mutation testing tools for different languages:

• JavaScript / TypeScript, C#, Scala: https://stryker-mutator.io
• Swift: https://github.com/muter-mutation-testing/muter
• Python: https://mutatest.readthedocs.io
• Rust: https://github.com/llogiq/mutagen
• Java & Kotlin: https://pitest.org

Conclusions

As you can see, mutation testing is able to identify changes in your code that are not covered by your tests, even when your code coverage can be 100%. After running this very same exercise with the GoodNotes engineering team we reached some conclusions we’d like to share with you:

• Coverage by itself without assertions doesn’t help.
• This is not the fastest tool, but that doesn’t mean it’s not interesting. It means it’s not designed to be used with slow test suites.
• Evaluating mutations only on files changed for every PR would be a nice integration point for CI.
• More interesting than code coverage.
• When you find a mutation surviving, it’s a chance to include a test or refactor your code.
• It’s complementary to other testing strategies and coverage (obviously).
• Can help to identify coupling sometimes.
• Not safe for slow test suites.
• Worst naming ever.
• Some mutations would never be applied by humans or are equivalent so this means → Bad signal/noise ratio for us…
• This strategy demonstrates how type safety and some FP features to reduce risk when coding.
• A good starting point could be to include it for incremental changes in your PRs.
• Way more useful in 1979!

This article was written by: Pedro Gómez & Tomás Ruiz-López, Senior Software Engineers at GoodNotes.

Who watches the watchers? Mutation Testing was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

GoodDevs are at NSSpain 2022 September 2022! After more than 2 years without on-site conferences, our engineering team decided to join one of the biggest iOS conferences in Europe, NSSpain X — we couldn’t say no to the chance to participate with one speaker and also sponsor NSSpain, a great event full of awesome speakers and top iOS devs.

Our team got to Logroño on Wednesday night. Nine developers, five from the iOS team and four from the cross-platform team, got ready to plan and review all the talks and speakers participating at the event the next day. After a thorough review, we decided there were many talks we were excited to hear, including “Composable Architecture at Scale” by Krzysztof Zablocki, “Improving the iOS development process guided by technical metrics” by Jessica Hernández and obviously, “Swift WebAssembly + GoodNotes, a cross-platform story!” by myself!

The first day started and we couldn’t be happier. We arrived together, ready to enjoy the talks with the iOS community. “Improving the iOS development process guided by technical metrics” was one of our favorite talks! Jessica explained how to use tools to measure, improve and act accordingly to improve development workflows guided by metrics.

On the afternoon of the first day, Pedro (the author of this post btw) gave a talk explaining our experience and technical details on how we’re developing GoodNotes for other platforms like Windows, Android, or web browsers reusing the iOS codebase. Pedro’s talk covered in detail how we crafted our cross-platform project using WebAssembly + Swift and explained some interesting technical challenges and solutions.

When the day was over, we gathered together again and reviewed the next day’s talks. Again talks like “How to choose the right branching strategy for your team (and why it matters!)” by Isabel Barrera, and “Rewriting SoundCloud in SwiftUI” by Matias Villaverde and Rens Breur got our attention.

As expected, Isabel’s talk was fantastic — covering different branching strategies for version control systems was an inspiration for us as a team because it made us think twice about our use of Git as VCS in our mono repository. We also had the chance to speak to her in person during the breaks about the event, Logroño, and our projects!

On Friday afternoon, the event ended, and it was time to head home. We had an awesome time at NSSpain! Our team works remotely and having the chance to see each other on-site in events like this is something we love.

Hear what the team has got to say:

“The conference went well, and we even randomly chatted with several potential candidates! And it was satisfying seeing people walking around with GoodNotes tote bags each day! ”

— Miguel Ángel Díaz, Senior iOS Engineer

“Pedro’s talk was one of the most technical meetings in the whole conference. Also, he was the only one using swift outside of the iOS/macOS environments.

It felt welcoming to attend this kind of event with the GoodNotes teams; considering that most of us are working remotely, it is a great opportunity to share time with your workmates, meet each other, and obviously have fun together.”

— Francisco Javier Trujillo Mata, Senior iOS Engineer

“Going back to an in-person event has been a great experience. I was able to meet many people from my team for the first time, see Pedro’s talk, and speak with many known and unknown faces from the community. Pretty interesting talks, people, and lots of fun!”

— Pablo Carcelén, Senior iOS Engineer

We had a wonderful experience at NSSpain. The talks were great. It was very interesting to see how other companies solve similar problems that we’re facing and learn about new topics from some great presenters. But if there’s something that makes NSSpain particularly unique, it is the social aspect. Perhaps motivated by the very first in-person NSSpain after 3 years, the atmosphere was perfect. Everyone was super approachable, and we had some fantastic talks with speakers and other attendees during breaks and social events planned by the organisers. It was also a great opportunity to meet in-person some team members that many of us didn’t have a chance to meet yet.

Our colleague Pedro showed once again his excellent presentation skills. In 45 minutes he managed to give a great overview of the past, present and future of Cross-Platform, give credit to the team, promote GoodNotes and share that we’re hiring. Nice work, buddy!

— Juanjo Ramos Rodríguez, Engineering Manager

Did you go to the NSSpain this year and if yes, how did you find it? Leave a comment below! Our team loved it and we will be back next year and will try to be on the stage again - see you there?

This article was written by:
Pedro Gómez is a Senior Software Engineer focused on new technologies, open-source, clean code, and testing. He is now working as a Senior Software Engineer in the cross-platform team at GoodNotes.

GoodDevs at NSSpain 2022 was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Case Study on Swift & Web Assembly Performance

WebAssembly is a significant component of the GoodNotes Web project. It is powerful yet challenging to adopt as it is relatively new and lacks community resource support. The performance issue is one of the main challenges we are passionate about resolving; as in GoodNotes, we deeply care about user experiences and want to make sure GoodNotes is as smooth and slick across all platforms.

Unlike most previous performance improvements we’ve done in the past where all the solutions applied were related to the UI layer or specific hot paths, this time we decided to go one level deeper in our analysis.

In this blog post, we break down how we found a performance issue in our app for a specific toolchain (Swift WebAssembly) and fixed it — if you like performance case studies, keep reading!

Defining the Environment

Our first idea was to make a comparison using Unit Tests in order to check the exact same piece of code on different platforms and compare the execution times. In this way, we could have a slight idea about how slow it is to run Swift WebAssembly code compared to pure Swift Code.

The platforms to compare were:

1. Swift Natively (running in macOS)
2. WASMER (using WebAssembly binary)
3. Chrome (using WebAssembly binary)

Thanks to WASMER, we can execute the WASM binary generated by the unit tests easily on our computer without using any browser. As you can imagine, using WASMER is useful just as a reference for us — in the end, we’re interested in executing it inside the browser.

Keep in mind as well, that one of the reasons why the performance is different between the platforms is because the toolchain itself is different. There are some specific libraries used in Swift WebAssembly that are different to Native Swift. A really interesting example is the libc :

• Web Assembly: https://github.com/WebAssembly/wasi-libc
• Linux Native: https://launchpad.net/ubuntu/+source/glibc

The Chosen Unit Test

We were trying to identify some expensive operations within the project that we’re just using purely Swift for (we can also execute Javascript code from Swift, so these examples aren’t valid for the purpose of this specific task). As we noticed the issue was related to the networking layer, we decided to use a profiler and find the point taking most of our execution time. After using the profiler we noticed there was a huge JSON string being parsed and taking too long to finish. Once the expensive operation was identified, we decided to use it as a reference for our unit tests. We saved the JSON we were parsing and noticed it was a huge one (5.5MB actually) and used it to run a unit test in order to measure the execution time before making any conclusions.

The test we wrote was something like this:

func testDeserialize_NotesHugeFromMemory() throws {
    let notesTextJSON = URL.fetchNotesHugeJSON!
    let notes = try JSONDecoder().decode(NotesData.self, from: notesTextJSON)
    XCTAssert(notes.data.count > 0)
}

Keep in mind the meassure functionality from XCTest is not available in Swift Web Assembly yet, so this is why we didn’t use it here.

Analyzing Results

Now that we have everything ready for running the test and checking the output, it’s time to review the results in terms of execution times on the following figures:

Outputs

1. Natively & NO OPTS
   Test Case ‘HybridRenderingFetchTests testDeserialize_NotesFromMemory’ passed (0.697 seconds)
2. Natively & OPTS
   Test Case ‘HybridRenderingFetchTests testDeserialize_NotesFromMemory’ passed (0.597 seconds)
3. WASMER & NO OPTS
   Test Case ‘HybridRenderingFetchTests.testDeserialize_NotesFromMemory’ passed (2.026 seconds)
4. WASMER & OPTS
   Test Case ‘HybridRenderingFetchTests.testDeserialize_NotesFromMemory’ passed (1.84 seconds)
5. Chrome & NO OPTS
   Test Case ‘HybridRenderingFetchTests.testDeserialize_NotesFromMemory’ passed (5.542 seconds)
6. Chrome & OPTS
   Test Case ‘HybridRenderingFetchTests.testDeserialize_NotesFromMemory’ passed (4.464 seconds)

At this point, I was quite disappointed with the Swift WebAssembly performance in general.
Honestly, I was expecting numbers to be approx. 20% slower, but I never expected this huge difference; for an end-user, it means the app is about 7 times slower…

As you may have noticed, there is a difference in our execution times depending on the optimizations applied. Remember that all the compilers offer a way of setting some Optimization Flags used during compilation. Usually, when running Unit Tests, all these flags are disabled; however, we are also interested in seeing what the real end-user behaviour will be, so that’s why we executed the unit test in both scenarios.

• Testing a package without optimization flags

swift test

• Testing a package with optimization flags

swift test -Xswiftc -O

Don’t Give Up Yet!

When I finished measuring, I didn’t want to give up and present these numbers because I was thinking to myself, “something else must be wrong over here”, so I decided to share these numbers with the Swift WASM community to see if I could find some lights of hope there. After some conversations with the principal maintainers of the Swift WebAssembly toolchain, they agreed that these numbers were too strange. They started to investigate deeper the reason for it and quickly found a mistake: some of the libraries being shipped in the toolchain were being generated in debug mode instead of release mode. More concretely, the library that was affecting us was Foundation.

Here you have the PR where they solved the mistake:
https://github.com/swiftwasm/swift/pull/4355/files

Updated Results After Applying the Fix

Once we identified the issue and updated the toolchain, we tried to run the test again. Take a look at the numbers once more:

As you can see, execution times are now closer to the native executions — that’s amazing! If we compare before vs after just focussing on Chrome & Optimizations, we are now executing the same code almost 3 times faster. This is a massive improvement!

For me, the conclusion of this story is that sometimes we just need to speak with the appropriate person. Just by dedicating some time and sharing information we have been able to improve the performance of our app without a single line of code being changed.

Extra Ball

After the fix, all the libraries are being compiled in RELEASE mode, and the binary generated .wasm is now lighter as well:

From:

After stripping debug info the main binary size is 17.55 MB

To:

After stripping debug info the main binary size is 15.97 MB

After compressing the WASM binary before generating the bundle, our production binary is now about 1.6 MB lighter.

This article was written by: Francisco J. Trujillo, a Senior Software Engineer focused on new technologies, open-source, clean code, and testing. He is now working as a Senior Software Engineer in the cross-platform team at GoodNotes.

Tested and Fixed — A step forward in shipping GoodNotes Web Viewer was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

And how it’s helping cross-platform projects at GoodNotes

Almost 4 years ago, a Swift Evolution Proposal by Chris Lattner was implemented, and one I thought I would never use: “SE0195- Introduce User-defined ’Dynamic Member Lookup’ Types”. Dynamic Member Lookup Types is a language killer feature that will let you write Swift in the way you would expect from languages like JavaScript or Python. However, in a world where statically typed languages and compilers are trending, why do I think this feature is so relevant? If you find my question interesting, just keep reading.

Thanks to DML you can write Swift code like this:

@dynamicMemberLookup
struct Foo {
    subscript(dynamicMember bar: String) -> String {
        // Do what you need to do here with the param and return any
        // type specified on the function.
        return bar
    }
}

Whenever you add the “@dynamicMemberLookup” annotation, the compiler will force you to implement a subscript function like the one you can read above and will let you write code like this:

let foo = Foo()
let anything: String = foo.anything
let anything2: String = foo.anything2
let anything3: String = foo.anything3

As you can see, there is no attribute declared with names like “anything”, “anything2” or “anything3”. However, the Swift compiler will let you use these variables and will not break the build when you use them! You can even create different subscript methods if you want and return different types if needed!

@dynamicMemberLookup
struct Foo {
    subscript(dynamicMember bar: String) -> String {
       return bar
    }

    subscript(dynamicMember bar: Int?) -> Int? {
       return bar
    }
    
    subscript(dynamicMember bar: Int) -> Int {
       return bar
    }
}

As a natural extension of DML, a new Swift feature named “Dynamic Callable” was born. A similar feature is already implemented in other languages like Kotlin but with a different name. You can find more information here. This is another nice feature that allows you to invoke functions on top of struct/classes instances without any function name like this:

@dynamicCallable
struct Foo {
    func dynamicallyCall(withKeywordArguments args: Int) -> Int {
        ....
    }
}

let fooInstance = Foo()
let bar = fooInstance()

I thought I would never need a syntax like this in a language like Swift. We always try to use the compiler to reduce complexity in our software and help us to develop faster. Thanks to the compiler we can validate part of our implementation in build time, and this is something we use more every day. However, when you need to interact with languages like JS or Python this API will really simplify the way you write code. But remember, with great power comes great responsibility! Just because you can now access any property without the compiler breaking your build, it doesn’t necessarily mean this code is safe. You now have to ensure your DML implementation will always behave accordingly and will not crash in runtime.

Why is this feature so important for us? Because we are implementing a really cool project where we need to interact with JavaScript via Swift code. Actually, we write JavaScript code using Swift, so we need to access different APIs that are not declared in build time. The code we write heavily relies on the DML feature, and thanks to this language capability we are able to access any JavaScript function/method/variable/instance with an easy-to-read and clear syntax. We just need to be careful and ensure our code works as expected and we have no typos, just as if you were writing JS.

Let me show you what our code looks like using this feature with a simple example:

class HTMLCanvas {

    private(set) var canvas: JSObject
    ....
}

private extension HTMLCanvas {
    func applyStyle(_ size: PSize) {
        let style = self.canvas.style.object!
        style.width = .string(size.width)
        style.height = .string(size.height)
    }
}

As seen above, we can access an attribute named “style” and modify the value easily without any previous declaration of these values as part of the “JSObject” implementation. This is how the “JSObject” class implementation is done:

@dynamicMemberLookup
public class JSObject: Equatable {
    ....
    /// Returns the `name` member method binding this object as `this` context.
    ///
    /// e.g.
    /// ```swift
    /// let document = JSObject.global.document.object!
    /// let divElement = document.createElement!("div")
    /// ```
    ///
    /// - Parameter name: The name of this object's member to access.
    /// - Returns: The `name` member method binding this object as `this` context.
    @_disfavoredOverload
    public subscript(_ name: String) -> ((ConvertibleToJSValue...) -> JSValue)? {
        guard let function = self[name].function else { return nil }
        return { (arguments: ConvertibleToJSValue...) in
            function(this: self, arguments: arguments)
        }
    }
    ....

Really cool, isn’t it? You can find many more examples of DML usage on JavaScriptKit, an open-source project developed by the Swift WebAssembly team.

For us, using this feature improved our code readability a lot, but there were some challenges we needed to face as well. For example, it forced us to evaluate optional values we knew weren’t null frequently when accessing values we knew were valid in runtime because the DML API was configured to return an optional value. We also found that Xcode navigation doesn’t work when trying to inspect a DML value, so this is an obvious downside we’ve faced when using this API.

Is there any improvement we can get on top of this feature? Sure, we can add types definition on top of our DML implementation! There are some APIs declared on dynamic languages like JS we can wrap with a type definition and implement using DML. Actually, this is a frequently-used solution based on a software design pattern called adapter/wrapper. A simplified version of one possible implementation in Swift would look like this:

struct Style {
    ....
    var width: String? {
        get {
            // Read from the JSObject using DML here
        }
        set {
            // Write in the JSObject using DML here
        }
    }
    
   var height: String? {
       get {
           // Read from the JSObject using DML here
       }
       set {
           // Write in the JSObject using DML here
       }
   }
   ....
}

struct HTMLDiv {
  let style: Style
}

Based on these types you can now write type-safe code checked by the compiler in build time like this:

div.style.width = "100px"
div.style.height = "100px"

The compiler will let you know if you write code that is not correct in build time.

div.style.width = 3 // Build error because width should be a String not an Int

The better you design your type, the better API you’ll be able to provide. The more information you add to your types, the safer your code will be to develop. Here you have an example of how you could use Swift enums to define the values a width or height param can accept instead of just a plain String:

enum CssSize {
    case pixels(value: Int)
    case em(value: Int)
    case percentage(value: Float)
    case auto
    case maxContent
    case minContent
    ....
}

However, adding a type definition on top of already existing APIs is a huge effort! So while the type definition is developed, we can still use DML to access any value in runtime. Keep in mind that this feature will help you to invoke functions and methods declared by you and your team in languages like JS from Swift and create your own type wrappers on top of the DML invocations.

This article was written by:
Pedro Gómez is a Senior Software Engineer focused on new technologies, open-source, clean code, and testing. He is now working as a Senior Software Engineer in the cross-platform team at GoodNotes.

Dynamic Member Lookup in Swift, a hidden gem! was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Keep It In Mind Since Day 1

When we start a new project, no matter what technology or stack we are using, there are always a bunch of tools we configure in order to simplify some tasks. Linters, code formatters, code coverage tooling, etc. Configuring all these tools takes time, but it’s time well spent because it helps us to avoid repetitive tasks in the future — from formatting in our code to checking whether our build and tests are passing. That’s why you should keep it in mind from the very first day. The usage of certain tools enables us to work way faster and get a development pace we couldn’t achieve otherwise. In this post you can find a list of tools we use in different technologies/stacks and why we find them interesting.

Automate Linters and Formatters

These are the keys to success if you want to avoid comments like this on your pull requests:

Swiftlint, ESLint, Prettier, or PyLint are just some examples. These tools help not only to automatically format our code but also to ensure we follow the coding convention the team specified.

Another example is the configuration of rules to avoid common patterns in our code, like the usage of the famous JavaScript “console.log” or force unwraps on Swift. You can even create your own custom rules if needed to automatically break the build if there are any rules the new code doesn’t comply with.

CI & CD

It is fundamental to ensure the changes we’ve done in our codebase make the build and tests pass automatically. But what about deployment? If you, my dear reader, are an iOS developer, how long have you been waiting for XCode to build archive your app on your own laptop? Our suggestion is to start every project working on CI & CD tasks. We are using GitHub actions and Circle CI right now, but any custom Jenkins configurations or any other tool will work for you as well.

For every new PR, there are some jobs we’ve configured to build our projects, evaluate our linters, run our tests and deploy new versions if needed. This automated process empowers us to spend our time on what really matters: building the best possible GoodNotes app for our users.

Best Tools For the Job!

There are tons of open-source tools you can use when building your project. Some of them can speed up your development process significantly. That’s why we spend time looking for the best tool for the job whenever we are working on our app.

There are some libraries, quite similar between platforms, that we always use on our projects. Here you have an interesting list:

There are some libraries, quite similar between platforms, we always use in our projects. Here you have an interesting list:

• Screenshot testing libraries: Swift snapshot testing library + cypress and the visual testing tooling are our favourites. It helps us to ensure our app shows the expected UI using pixel-perfect precision!
• Data serialisation tooling: We heavily rely on Swift protobuf implementation. It makes our life way easier and the performance is awesome!
• Dependency management libraries: CocoaPods, Swift Package Manager, yarn, and npm, are just some of them. We couldn’t work with these tools, literally.
• Loggers: DataDog’s logging tool hidden under an adapter or connected to loggers like CocoaLumberjack.
• Styling tools: StyledComponents and Auto Layout are two great examples. Best tool for the job on two different platforms, React and iOS. Combined with a design system, it will make your UI shine!

Plan Ahead

However, this is not only about libraries and tooling, working smarter is an attitude as well! That’s why we work using a 6-week development cycle with a dedicated planning period in advance. Planning before coding, thinking before writing a single line of code — that’s our best tool! You think way faster than you code, so we recommend taking the time to think and plan before tackling any task. Review the requirements, take notes, design your solution and ask for feedback before implementing anything. If you plan, it serves as your first iteration, so you’ll be able to work more efficiently later on as this will speed up the feedback process and you can iterate again as soon as possible.

These are the tips and tools we use in our Engineering Team for working smarter, not harder. Are there any of your favourites we didn’t mention? Please, write a comment below and let us know!

This article was written by:
Pedro Gómez is a Senior Software Engineer focused on new technologies, open-source, clean code, and testing. He is now working as a Senior Software Engineer in the cross-platform team at GoodNotes.

How We Work Smarter, Not Harder was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, we are going to focus on typography and how we can customize it, without losing the ability to adapt it for accessibility.

Dynamic Type

Dynamic Types in iOS are semantic categories that assign size and weight to the font of a text given their relevance in the user interface. These can be headlines, titles, or footnotes, among others.

The key benefit of setting your font sizes and weights through these categories is that your text will adjust accordingly when the accessibility settings are changed. If your users decide to increase the font size, each category will increase proportionally to match the selected system setting. Otherwise, if you set fixed values for your font size, your users won’t be able to benefit from that feature.

Customizing dynamic types

Default dynamic sizes have pre-determined font sizes and weights that make sense for each category. However, this does not mean we cannot customize our own if we want to change the default font, size or weight for a given dynamic type.

In our case, we want to perform small changes to the sizes of each text style, and have it available in different weights (regular and bold). Style Dictionary also allows for generating custom font style code, but again, the default behavior does not exactly match our needs; therefore, we decided to extend its functionality with a custom plugin that uses a Handlebars template:

This creates an extension on UIFont that computes a font for a given text style, applying our customized size and weight for such style. An example of the generated code looks like:

The extension on UIFont allows us to easily use it to programatically assign a font to any UIKit component, such as a UILabel:

Conclusions

Following the approach we described in the previous post about colors, we are able to generate all custom font styles we need in our iOS application, from a description provided by our designers using Figma. It results in a nice extension of UIFont that maintains the same benefits regarding accessibility and responsive design, while having a nice API to consume.

Did you like what we are doing? Do you want to join us, and help us shape up the future of GoodNotes? We are hiring!

This article was written by:
Tomás Ruiz-López is a Senior Software Engineer working in the iOS team at GoodNotes. He enjoys learning new technologies in the Apple ecosystem and looking at them from the prism of Functional Programming. He has developed several open source projects related to the Bow library, an attempt to bring FP concepts into Swift.

Towards a Design System in iOS: Typography was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Consistency is key to achieve a good UI/UX in an app. From a user’s perspective, it is paramount that things that are the same, look the same, and are used the same. This helps them relate knowledge from previous features in your app, or in the system, and quickly learn how to use new functionality. But that does not stop there; from a developer’s perspective, it also has great benefits, as existing components and interactions can be easily reused.

As part of our efforts to enhance consistency across GoodNotes, our team has been working on a Design System: a library of tokens and components that we can refer to when implementing new features into the app. It serves as a common language between designers and developers to unambiguously refer to certain items in our software and improve the way we work.

We are still in the process of adopting it, but we found some interesting aspects that we would like to share with you. In this first post, we will focus on colors.

Colors in iOS

In our project, we try to use named colors defined in our Assets in Xcode. This lets us define semantic colors that include variants for light and dark modes, and get the right one without too much hassle.

This also lets us have a visual representation of all colors in the application, and verify that they are correct in both themes. These colors are available through the Interface Builder, or we can instantiate them using the UIColor(named:) initializer.

There is a small problem though: our designers usually work in Figma, not in Xcode. We need a way to import their list of colors into our project. Moreover, when they change something, we don’t want to go over the list of colors and manually update them in our Assets.

There are tools to automate the generation of colors from Figma, like Style Dictionary, and it not only works for iOS, but for other platforms, which may become useful in the future. However, if you take a look at the generated output, it has two main shortcomings:

1. It does not use named colors in Assets.
2. It does not distinguish between light and dark mode colors.

Tweaking Style Dictionary

Fortunately, Style Dictionary is customizable through plugins, so we wrote one to let us customize the output to match our needs. The task became surprisingly easy thanks to using Handlebars, a template system that can render our data in the format we would like.

First, we created a template for named colors that allows us to put together both light and dark versions of a color. It took us a bit of reverse engineering how Xcode represents colors in the colorset folders.

The template looks like:

Most of the template corresponds to the JSON format that Xcode uses to represent named colors, but the values enclosed by double curly braces ({{ }}) are the gaps that we can fill with light and dark variants of our color. We run this template for each color our designers define in Figma.

Finally, in order to have a convenient way of using these colors programaticaly, we generate a custom UIColor extension with values for the generated colors:

This way, whenever our designers refer to the color GoodNotesDenim600, with variants for light and dark mode, we only need to call UIColor.goodNotesDenim600, and the system will handle variants for us. If, for some reason, our designers decide to add new colors, or update existing ones, we only need to generate them again.

In case we transitioned to use SwiftUI (or you are already using it), our template to generate colors wouldn’t change much:

Similar to its UIKit counterpart, this offers a good API to work with colors in SwiftUI. The Assets catalog is shared, so we can even have both versions (UIColor and SwiftUI.Color) coexisting in the same code base.

Conclusions

Style Dictionary is a very useful tool to translate resources provided by designers using Figma, into resources that can be targeted to different platforms, like iOS in our case. However, it has some shortcomings when it comes to dealing with named resources, and light and dark modes. Thanks to its powerful extension capabilities, we can customize the generation process to fulfill our needs and unlock additional benefits, like nicer APIs to work with colors.

Did you like what we are doing? Do you want to join us, and help us shape up the future of GoodNotes? We are hiring!

This article was written by:
Tomás Ruiz-López is a Senior Software Engineer working in the iOS team at GoodNotes. He enjoys learning new technologies in the Apple ecosystem and looking at them from the prism of Functional Programming. He has developed several open source projects related to the Bow library, an attempt to bring FP concepts into Swift.

Towards a Design System in iOS: Colors was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.

We love sharing these experiences with you and hearing your feedback! And we like it so much that we have decided to take a step further and share something more with you.

This is the first post in our Engineering Blog!

Here, you will find how our GoodEngineers build the internals of our product. With this blog, we aim to give you more insights about how it is working at GoodNotes from a technical point of view. You will read about our particular take to different problems that, most likely, you will also find in your projects as well, and we will offer tips and tricks that may not be so widely known. But we don’t want this to be unidirectional! We’d love to hear your feedback and hints on how you tackle the same problems: we are here to learn as much as to share.

In this blog, you will find content from our different teams, ranging from iOS Development to Machine Learning. Our engineers are eager to start posting content, but we’d also like to hear from you: which topics would you like us to cover?

Finally, we want to remind you that we are hiring! If you like the things we are doing, and think you can contribute to make our product better, take a look at our openings. We’ll be glad to welcome you to our team.

Welcome to our Engineering Blog! was originally published in Engineering At GoodNotes on Medium, where people are continuing the conversation by highlighting and responding to this story.