DEV Community: Angel G. Olloqui

AI & Automation 2025 Yearly Wrap-Up

Angel G. Olloqui — Fri, 23 Jan 2026 11:06:50 +0000

This post is an adaptation of an internal wrap-up I shared at Playtomic to celebrate our AI journey in 2025. I've kept the public-facing industry insights and general learnings while removing internal-only details.

Happy 2026! 🎉 As we kick off the new year, let's take a moment to celebrate 2025—the year AI went from "cool experiment" to "wait, this is actually can change everything." This wrap-up captures the industry's most transformative developments alongside a look at how AI and automation are becoming integral to modern product development and operations. 🎊

🌍 AI IN THE INDUSTRY

💡 What happened in AI this year? A lot. Here's what you need to know:

🧠 The Tech Race Heats Up

OpenAI still leads, but the competition is fierce. China's open-source models (DeepSeek, Qwen, Kimi and GLM) are gaining ground fast, while Google's Gemini 3 Pro dominates reasoning benchmarks and Claude remains the go-to for software development.

Reasoning models are evolving rapidly. These "think before you answer" AIs can now plan, reflect, self-correct, and work over longer time horizons—making them smarter problem-solvers. But humans still outperform AI on Humanity's Last Exam, a benchmark designed to test the very edge of human knowledge. For now, we're still the champions. 💪

Multimodal, Image and Video AI just leveled up. Google's Veo 3 and OpenAI's Sora 2 now generate high-quality 8-second videos with audio and sound effects.

First World models on stage. Google also dropped Genie 3 and Runway GWM-1, interactive world models that creates virtual environments you can explore and interact with in real time. Expect lots of innovation around this on 2026 🎬

MCP (Model Context Protocol), aka "USB-C for AI," is officially everywhere—companies are racing to support it, even if users are still figuring out where to plug it in. 🔌 Think of it as the universal connector AI has been waiting for.

💰 Industry & Infrastructure

Mega investments are pouring in. Case in point: Stargate—a $500B, 10GW US mega-cluster backed by Altman, SoftBank, Ellison, and Trump. 4 million GPUs working together! 🤯

Chips are still the bottleneck. Nvidia produces ~90% of AI's horsepower while US controls 75% of global AI capacity—though China is racing to close the gap despite chip export restrictions. 🔬

Electricity is now the new limiting factor. China added 400GW of power infrastructure in 2024 vs 40GW in the US. Meanwhile, some companies are exploring space-based solar power plants— the sky isn't the limit anymore. 🛰️

From courtroom to conference room. After a wave of lawsuits from Disney, BBC, Getty Images, The New York Times,… over unauthorized training data, 2025 brought détente: licensing deals. Now, content partnerships are the new normal—and a fresh revenue stream for publishers. 🤝

🏢 Enterprise Adoption

2025 was the year of AI agents—mostly text-based, but voice is ramping up. Still, most companies are stuck in pilot phase. Meanwhile at Playtomic? We said "hold my racket" 🎾 and shipped agents straight to production.

Executives are optimistic, but expertise lags behind. 97% of executives believe AI will transform their industry and company, yet only 35% say they have the expertise needed to drive those transformations. It seems everyone wants to ride the AI wave, but most are still looking for their surfboard. 🏄‍♂️

"Supernova AI startups" are a new category: AI companies growing faster than anything we've seen before. 🚀

🌐 Politics & Jobs

AI politics hardened. The US doubled down on "America-first AI," Europe's AI Act stumbled, and China expanded its open-source ecosystem and domestic chip ambitions.

Defense goes all-in on AI. The US Army dropped a $10B deal with Palantir, NATO adopted Maven in record time, and the Pentagon brought in top companies for AI experiments. From "maybe we shouldn't" to "here's $200M"—quite the vibe shift🛡️

Job shifts happening slowly. AI is beginning to affect some roles (with up to 7% future displacement predicted by Goldman Sachs), but impact remains modest. Meanwhile, new jobs are emerging: AI ethicists, ML engineers, data specialists…

⚖️ Safety & Ethics

Make it safe. There's strong public interest in alignment (making sure AI does what we want), reliability, and explainability—but budgets remain relatively low.👿

From "vibe coding" to "vibe hacking". AI is already being used for cyberattacks, exploiting code faster than humans can fix it. In parallel, several projects and companies are also exploring AI as security researchers 🔓.

Deepfakes and AI-generated video are raising new ethical and legal questions, while researches show models can now "fake alignment" when being watched.

AI Model Welfare debates are starting to emerge. Researchers and ethicists are now discussing whether AI should merit moral considerations—raising questions about consciousness, sentience, and the ethical treatment. Still early, but more to be expected as systems become increasingly sophisticated. 🤔

🔬 AI Beyond Tech

Chemistry: AlphaFold and ProGen3 are predicting 3D protein structures and accelerating drug and material discovery.
Healthcare: AI is revolutionizing diagnostics and enabling personalized cancer treatments.
Robotics: Major hype around humanoid robots like Figure 3 and Tesla's Optimus but still far from deployment. Meanwhile, autonomous driving is ramping up fast, with Waymo leading with more than 14M rides in 2025 without human drivers.
Other cool stuff: AI is now predicting weather, spotting exploding stars, detecting wildfires, and even trying to understand dolphin language. 🐬

🎾 AI AT PLAYTOMIC

💡 How we've been applying these trends:

🏁 Product Innovation

We've integrated AI into several key areas of our product:

AI-Driven Customer Care: We've deployed super agents that instantly answer questions from clubs and players, significantly improving response times and customer satisfaction.
Personalized Insights: Using AI, we've built dashboards for clubs that provide tailored analytics and reports, helping them make better data-driven decisions.
Virtual Buddies: AI-generated avatars now help in our educational content, speaking multiple languages and making our product more accessible globally.
Conversational AI: We experimented with AI-driven Whatsapp chatbots to explore new ways of user interaction and distribution strategies.

🧑‍💻 Engineering & Operations

AI has transformed our internal workflows:

AI-Powered Development: Tools like Cursor and Claude Code have changed how we build, helping us write code faster, plan better architectures, and explore complex codebases.
Operational Automation: We've automated repetitive tasks in data analytics, QA processes, and customer support triage, saving hundreds of hours of manual work every month.
Fraud Detection: Our AI-powered systems are actively identifying and blocking fraudulent transactions, protecting our ecosystem.

🤔 DID YOU KNOW?

Universal Search: Tools like Notion AI now pull information from multiple sources (Slack, GitHub, email), creating a single entry point for knowledge.
Plan Mode: The shift towards "spec-first" development—where AI drafts a plan before execution—is leading to more thoughtful architecture and fewer mistakes.
Breaking Silos: AI is enabling unprecedented collaboration between engineers and non-engineers, allowing PMs and designers to contribute more directly to the technical process.

📚 WANT TO LEARN MORE?

Here are some fantastic resources to level up your AI game:

📖 Reading: AI Engineering – Grab this book if you're ready to go deep into foundation models and AI applications.
🎬 Watching: The Thinking Game – This documentary follows DeepMind's journey from AlphaGo to AlphaFold. It's a must-watch!

Buckle up—2026 is coming in hot! 🚀 We're not slowing down. The future isn't just arriving—we're building it, one serve at a time. Game on! 🎾⚡

Adding multi device previews in Xcode and Android Studio

Angel G. Olloqui — Wed, 05 Apr 2023 09:48:47 +0000

Developing with SwiftUI and Jetpack Compose is very user-friendly. Both frameworks offer a highly readable declarative syntax and a live preview feature that updates in real-time while coding. This live preview allows developers to easily configure various device settings, although it can be a bit cumbersome to specify multiple device factors. At Playtomic, we have created a simple utility for both platforms that allows us to run our previews on a predefined set of devices. Here's what we did:

Android

This platform was the easy one, as it already supports aggregated annotations out of the box. All you need to do is include somewhere in your project:

@Preview(showSystemUi = true, device = Devices.PIXEL_4_XL, name = "Pixel 4 XL")   // big xxxhdpi
@Preview(showSystemUi = true, device = Devices.NEXUS_5, name = "Nexus 5")   // small-medium xxhdpi
annotation class MultiDevicePreview

And then just replace the usage of @Preview by @MultiDevicePreview in your previews:

@MultiDevicePreview
@Composable
private fun AMultiDevicePreview() {
    Text("Multidevice preview")
}

iOS

Things become a bit more complicated for iOS. Firstly, Xcode only recognizes previews that implement the PreviewProvider protocol. As a result, extending the interface with our custom version of MultiDevicePreviewProvider doesn't work. Instead, we created a second protocol to tackle this problem:

public protocol MultiDevicePreview {
    associatedtype DevicePreviews : View
    @ViewBuilder @MainActor static var devicePreviews: DevicePreviews { get }

    @MainActor static var devices: [PreviewDevice] { get }
    @MainActor static var previewName: String? { get }
}

And then, we provided a default implementation of the previews for those using the new protocol:

public extension PreviewProvider where Self: MultiDevicePreview {
    static var previews: some View {
        ForEach(devices) { device in
            AnyView(devicePreviews)
                .previewDevice(device)
                .previewDisplayName([previewName, device.rawValue].compactMap { $0 }.joined(separator: " - "))
        }
    }

    static var devices: [PreviewDevice] { PreviewDevice.allCases }
    static var previewName: String? { String(describing: Self.self) }
}

We also declared some predefined list of devices to simplify the management:

extension PreviewDevice {
    public static let iPhone14 = PreviewDevice("iPhone 14")
    public static let iPhone14Max = PreviewDevice("iPhone 14 Pro Max")
    public static let iPhoneSE = PreviewDevice("iPhone SE (3rd generation)")
    public static let allCases = [iPhone14, iPhone14Max, iPhoneSE]
}

extension PreviewDevice: Identifiable {
    public var id: String {
        rawValue
    }
}

With all of the above, you can make use of multidevice previews by conforming your preview to MultiDevicePreview and replace the method previews by devicePreviews like:

struct AMultiDevicePreview: PreviewProvider, MultiDevicePreview {
    static var devicePreviews: some View {
        Text("multidevice preview text")
    }
}

Not a huge difference, but a nice small addition to the toolkit!

Data Races with value types in Swift

Angel G. Olloqui — Fri, 26 Aug 2022 14:49:54 +0000

This week I had an interesting discussion around a possible data race condition due to wrong threading synchronisation when manipulating a value type (a String in this case) in a class.

The buggy code

final class MyClass {
    var token: String

    init(_ token: String = "") {
        self.token = token
    }

    func myMethod() -> Bool {
        token.isEmpty
    }
}

In a first look, this might seem correct. We have just a var with a String, which is a value type, and a method to just check if the token is empty that only calls the isEmpty from String. Straightforward code and safe right? well, it is OK as long as you do not introduce threading, but the moment you do it will not. Let me elaborate.

The test

If you run this test with Thread Sanitizer enabled:

 func test_data_race() {
        let sut = MyClass()

        DispatchQueue.concurrentPerform(iterations: 1_000_000) { i in
            sut.token = "\(i)"
            _ = sut.myMethod()
        }
    }

you will see this output:

WARNING: ThreadSanitizer: data race (pid=8329)
  Read of size 8 at 0x000107c1aab8 by thread T2:
    #0 closure #1 in DataTests.test_data_race() DataTests.swift:69 (Tests:arm64+0xde354)
    #1 partial apply for closure #1 in DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde3e4)
    #2 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:73675156 (libswiftDispatch.dylib:arm64+0x42f4)
    #3 _dispatch_client_callout2 <null>:73675156 (libdispatch.dylib:arm64+0x35dc)

  Previous write of size 8 at 0x000107c1aab8 by main thread:
    #0 closure #1 in DataTests.test_data_race() DataTests.swift:69 (Tests:arm64+0xde374)
    #1 partial apply for closure #1 in DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde3e4)
    #2 partial apply for thunk for @callee_guaranteed (@unowned Int) -> () <null>:73675156 (libswiftDispatch.dylib:arm64+0x42f4)
    #3 _dispatch_client_callout2 <null>:73675156 (libdispatch.dylib:arm64+0x35dc)
    #4 _swift_dispatch_apply_current <null>:73675156 (libswiftDispatch.dylib:arm64+0x43a0)
    #5 @objc DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde448)
    #6 __invoking___ <null>:73675156 (CoreFoundation:arm64+0x11c5ec)

  Location is heap block of size 32 at 0x000107c1aaa0 allocated by main thread:
    #0 __sanitizer_mz_malloc <null>:73675156 (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x51004)
    #1 _malloc_zone_malloc <null>:73675156 (libsystem_malloc.dylib:arm64+0x1527c)
    #2 DataTests.test_data_race() DataTests.swift:66 (Tests:arm64+0xde07c)
    #3 @objc DataTests.test_data_race() <compiler-generated> (Tests:arm64+0xde448)
    #4 __invoking___ <null>:73675156 (CoreFoundation:arm64+0x11c5ec)

  Thread T2 (tid=6246748, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: data race DataTests.swift:69 in closure #1 in DataTests.test_data_race()

So ThreadSanitizer is detecting a data race in the code when accessing the token.
What does it mean? basically you are making a wrong usage of the variable. It gets read and write operations concurrently but the variable itself is not protected, and the fact that it is a value type does not help.

What can this cause? it is undefined, but in practice most likely you will have a crash when compilation optimizations are enabled.

The fix

OK, so this simple code can crash when reading and writing the token in parallel from different threads! How can we fix it? we just need to make serial access to read/write. There are multiple ways of doing it (with different primitives), but this could be one:

final class MyClass {
    private let syncQueue = DispatchQueue(label: "com.test.myQueue", attributes: .concurrent)
    private var _token: String
    var token: String {
        get {
            syncQueue.sync {
                _token
            }
        }
        set {
            syncQueue.async(flags: .barrier) {
                _token = newValue
            }
        }
    }

    init(_ token: String = "") {
        _token = token
    }

    func myMethod() -> Bool {
        token.isEmpty
    }
}

As you can see, what we did is to protect the var by forcing serial writing to it, so multiple reading can happen but only 1 thread can execute a write at a time (the barrier waits for all previous readings to finish and postpones all subsequent read/write accesses till the write is done). The resulting code is slower to execute, but it is now safe.

Final thoughts

I wanted to share a few thoughts around this issue, that are common misconceptions in the Swift community:

❌ Value types are thread safe

Since the value type has a copy semantic, it may seem logical to think that they are inherently protected from data races. However, that is not the case. Swift does not guarantee thread safety in value types, so accessing any var from multiple threads is a potential data race condition. This issue of course does not apply to let variables since they are immutable.

❌ Value types are always copied

That is the semantic but not really what happens under the hood. When passing value types around, Swift compiler is smart enough to know if the copy is needed, removing unnecessary copies. In practice it uses a CopyOnWrite(COW) strategy, where it will make the copy only when the value is modified, but not when passed around. As a result, in most situations you will actually have a pointer to the same underlaying memory address even when using value types.

❌ Tests do always behave like production code

The fact that a test does not crash is no guarantee to assert that some code can not crash in production. Tests run in simulated environments and they normally have different compilation options than the ones in your final builds. For example, ARC will make aggressive optimizations when compiling with the proper options, so lots of unnecessary retain/releases will be removed from final builds. In this particular case, my test suit was not crashing, and I was only able to see some wrong usage by activating the Thread Sanitizer.

Extra reading

MVI in Playtomic mobile app

Angel G. Olloqui — Tue, 31 May 2022 12:06:15 +0000

Last summer we finally decided to move out of our classic MVP+UIKit/Android view architecture into a more modern one with SwiftUI/Compose as main actors for our view layer. Together with the UI framework changes, we found the need of switching to a more reactive architecture that better fits the nature of declarative UIs.

We spent some time analysing some of the most popular reactive architectures: MVVM, MVI and TCA. Without getting into much detail of our decision making (it would take a full post), we decided that MVI was the best fitting for our project. With it, we could get better separation of concerns and state management than in MVVM, unidirectional data flow, single source of truth and easy of testing, without the additional complexity added by TCA.

After around half a year working with MVI, the team is highly satisfied: all people in the team consider it a good/great choice and enjoys working with it, being the verbosity the only drawback.

Let us share a bit on how we do it:

The state management layer

This is how our MVI base class looks like in both platforms

open class BaseMVIPresenter<S: ViewState, A: ViewAction> {
    public var currentViewState: S { _viewState.value! }
    public var viewState: Observable<S> { _viewState }
    fileprivate let _viewState: MutableObservable<S>

    public init(initialState: S) {
        _viewState = MutableObservable(value: initialState)
    }

    func dispatch(action: A) {
        fatalError("Must be implemented by the children")
    }
}

open class MVIPresenter<S: ViewState, A: ViewAction, R: ActionResult>: BaseMVIPresenter<S, A> {
    private var middlewares: [MVIMiddleware<S, A, R>] = []

    public func with(middleware: MVIMiddleware<S, A, R>) -> Self {
        middlewares.append(middleware)
        return self
    }

    open func handle(action: A, results:  @escaping (R) -> Void) {
        fatalError("Must be implemented by the children")
    }

    open func reduce(currentViewState: S, result: R) -> S {
        fatalError("Must be implemented by the children")
    }

    override public func dispatch(action: A) {
        middlewares.forEach { element in
            element.handle(action: action, presenter: self)
        }
        handle(action: action) { [weak self] result in
            Executor.execute(inBackground: false) {
                guard let self = self else { return }
                self.middlewares.forEach { middleware in
                    middleware.handle(result: result, presenter: self)
                }
                self._viewState.value = self.reduce(currentViewState: self.viewState.value!, result: result)
            }
        }
    }
}


interface BaseMVIPresenter<ViewState, ViewAction> {
    val currentViewState: ViewState get() = viewState.value!!
    val viewState: Observable<ViewState>
    fun dispatch(action: ViewAction)
}

abstract class MVIPresenter<S : ViewState, A : ViewAction, R : ActionResult>(initialState: S) : BaseMVIPresenter<S, A> {
    override val viewState: Observable<S>
        get() = _viewState
    private val _viewState = MutableObservable(value = initialState)
    internal var middlewares = mutableListOf<MVIMiddleware<S, A, R>>()

    abstract fun handle(action: A, results: (R) -> Unit)

    abstract fun reduce(currentViewState: S, result: R): S

    override fun dispatch(action: A) {
        middlewares.forEach { element ->
            element.handle(action = action, presenter = this)
        }
        handle(action) { result ->
            Executor.execute(inBackground = false) {
                this.middlewares.forEach { middleware ->
                    middleware.handle(result = result, presenter = this)
                }
                this._viewState.value = this.reduce(currentViewState = this.viewState.value!!, result = result)
            }
        }
    }
}

fun <S : ViewState, A : ViewAction, R : ActionResult, T : MVIPresenter<S, A, R>> T.with(middleware: MVIMiddleware<S, A, R>): T {
    middlewares.add(middleware)
    return this
}

Note: In MVI there is no definition whether the data management part should be done in a presenter, view model or whatever. However, in our case we opted to call them "Presenters" to be more inlined with the rest of the app, but they are in practice maintaining state as classic ViewModel in Android.

Then, when building a feature, we need to provide the implementation of 2 methods:

handle: This method takes the actions triggered by some other component (normally the view) and handles the side effects. It emits new events (called "action results") with the results of the effects, like for example a network call. It does not perform any state management or manipulation, it just emits new result events.
reduce: Given a state and an action result, this method computes the next state of the view. Note that it behaves as a pure function, with no side effects.

In contrast with other simpler implementations of MVI, we opted to split the code into these 2 methods to isolate side effects from state manipulation, which make our tests much simpler and our overall solution more robust and clean. An added benefit is that there are no race conditions possible like in other architectures, since all calls to reduce are executed in serial with no partial updates possible.

In addition, we added an extra piece around the presenters, called Middleware, that are capable of reacting to events without doing state management. For example, we can add all analytics tracking into a middleware or all navigation actions. This way, our presenter stays purist, just doing the state management part, and we have a set of small middlewares with a single other purpose, making it once again easier to test and maintain.

Lastly, you can see how both platform implementations are quite similar, and they both avoid the usage of platform specific APIs like Combine or Flows (although they are used internally) to maximize code reusal when transpiling and also reduce the learning curve.

An example Presenter would look like:

internal class LessonDetailPresenter(...): MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>(LessonDetailState.none) {

    override fun handle(action: LessonDetailAction, results: (LessonDetailResult) -> Unit) {
        when (action) {
            is LessonDetailAction.onAppear -> loadLesson(results, lessonId)            
            is LessonDetailAction.tapConfirmCancelEnrollment -> unregisterFromLesson(results)
            is LessonDetailAction.resendConfirmation -> resendConfirmation(results)
            ...
        }
    }

    override fun reduce(currentViewState: LessonDetailState, result: LessonDetailResult): LessonDetailState {
        return when (result) {
            is LessonDetailResult.lessonLoading -> LessonDetailState.loading
            is LessonDetailResult.lessonLoaded -> LessonDetailState.detail(sections = result.lesson.mapToLessonDetail(me = userId))
            ...
        }
    }

    private fun loadLesson(results: (LessonDetailResult) -> Unit, lesson: LessonId) {
        results(LessonDetailResult.lessonLoading)
        activityService.fetchLesson(lessonId)
            .then { results(LessonDetailResult.lessonLoaded(it)) }
            .catchError { results(LessonDetailResult.loadLessonByIdFailed(error)) }
        }
    }
    ...
}

And some associated middleware for navigation:

internal class LessonDetailNavigator(...) : MVIMiddleware<LessonDetailState, LessonDetailAction, LessonDetailResult>() {

    override fun handle(action: LessonDetailAction, presenter: MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>) {
        when (action) {
            LessonDetailAction.tapOpenMaps -> openMaps(presenter = presenter)
            LessonDetailAction.tapAddToCalendar -> addLessonToCalendar(presenter = presenter)
            ...
        }
    }

    override fun handle(result: LessonDetailResult, presenter: MVIPresenter<LessonDetailState, LessonDetailAction, LessonDetailResult>) {
        when (result) {
            is LessonDetailResult.loadLessonByIdFailed -> dismiss()
            else -> {}
        }
    }
    ...
}

Our view layer

Then, our views basically just receive 2 parameters:

public struct LessonDetailView: View {
    @ObservedObject var state: ObservableViewState<LessonDetailState>
    let dispatcher: (LessonDetailAction) -> Void

    public var body: some View {
        ...
    }
}

@Composable
private fun LessonDetailView(
    viewState: LiveData<LessonDetailState>,
    dispatcher: (LessonDetailAction) -> Unit
) {
    ...
}

As you can see, we are making use of state hoisting for encapsulating the presenter injection (from the view layer, it does not know what class is behind the state management). This also makes our code much more reusable, and very easy to setup the previews, since we do not need to mock any data, service or presenter, just passing the view state down is enough. For this state hoisting we are making use of a parent UIViewController/Fragment, since our app is now a mixed app with only part of the views in SwiftUI/Compose. They look like this:

final class LessonDetailViewViewController: SwiftUIViewController<LessonDetailState, LessonDetailAction, LessonDetailView> {
    override func contentView(
        viewState: ObservableViewState<LessonDetailState>,
        dispatcher: @escaping (LessonDetailAction) -> Void
    ) -> LessonDetailView {
        LessonDetailView(state: viewState, dispatch: dispatcher)
    }
}

class LessonDetailFragment : ComposeFragment<LessonDetailState, LessonDetailAction>() {
    @Composable
    override fun ContentView(
        viewState: LiveData<LessonDetailState>,
        dispatcher: (LessonDetailAction) -> Unit
    ) = LessonDetailView(viewState = viewState, dispatcher = dispatcher)    
}

Where the SwiftUIViewController and ComposeFragment are base classes that inject the presenter and create the UIHostingController/ComposeView for using SwiftUI/Compose inside with the content returned by the concrete contentView method on each case.

Conclusions

There are tons of options and architectures to use with SwiftUI/Combine. In Playtomic, we opted for a MVI version where we have a clear separation of the different responsibilities, single source of truth and a simple and unidirectional data flow. It also allows for very simple views and easy transpilation between platforms, with
only one drawback so far: the extra boilerplate needed.

References

GoDaddy Studio’s Journey with State Management: Great article explaining some of the issues they found with MVP, MVVM and MVI in its simpler form. We find ourselves very aligned with their journey.

Automating rollout releases in Android

Angel G. Olloqui — Sat, 01 Jan 2022 10:14:06 +0000

As part of our new release process (weekly releases) we are also changing the way we are publishing the apps for users. Since it is now automatic, it is crucial for us to have a phased released in which only a small subset of our users get the latest build, increasing daily and acting as a "failsafe" in case of an important bug makes it into production.

For iOS, we can set the Phased Release + Publication Date option and the AppStore will handle it in your behalf, starting the release on a certain date and increasing the automatic updates to 1%, 2%, 5%... each day.

However, Google's approach is different. They do not offer a release date nor an automated phased release. Instead, they offer you with an API (and web dashboard) where you can set the percentage of users yourself at any time. This is in many senses much better than the Apple one, especially since this actually controls the releases and not just the automatic updates like in Apple, but it has a downside: it is all manual.

With our current setup of weekly releases and a phased released across 6 days (2%, 5%, 10%, 20%, 50%, 100%), this basically means having to update every single day the rollout amount manually. I am not sure about you, but having to enter every single day to click some button is the last thing I want to do.

Automating the release rollout

So, we wondered, if we have an API to control the rollout percentage, isn't that enough to make it automatic? what if we have a CI job that run every day and basically checks if there is an ongoing rollout release, and in that case increases the percentage? Let's see how we did it:

# rollout_update.py

import copy
import sys
import httplib2
from apiclient.discovery import build
from oauth2client.service_account import ServiceAccountCredentials
from oauth2client.client import AccessTokenRefreshError

TRACK = ('production')

# To run: rollout_update package_name json_credentials_path
def main():
  PACKAGE_NAME = sys.argv[1]
  credentials = ServiceAccountCredentials.from_json_keyfile_name(
    sys.argv[2],
    scopes='https://www.googleapis.com/auth/androidpublisher')

  http = httplib2.Http()
  http = credentials.authorize(http)

  service = build('androidpublisher', 'v3', http=http)

  try:
    edit_request = service.edits().insert(body={}, packageName=PACKAGE_NAME)
    result = edit_request.execute()
    edit_id = result['id']

    track_result = service.edits().tracks().get(editId=edit_id, packageName=PACKAGE_NAME, track=TRACK).execute()
    old_result = copy.deepcopy(track_result)

    print("Current status: ", track_result)
    for release in track_result['releases']:
        if 'userFraction' in release:
            rolloutPercentage = release['userFraction']
            if rolloutPercentage == 0:
                print('Release not rolled out yet')
                continue
            elif rolloutPercentage < 0.02:
                release['userFraction'] = 0.02                         
            elif rolloutPercentage < 0.05:
                release['userFraction'] = 0.05
            elif rolloutPercentage < 0.1:
                release['userFraction'] = 0.1
            elif rolloutPercentage < 0.2:
                release['userFraction'] = 0.2
            elif rolloutPercentage < 0.5:
                release['userFraction'] = 0.5
            elif rolloutPercentage < 1.0:
                del release['userFraction']
                release['status'] = 'completed'
            else:
                print('Release already fully rolled out')
                continue        
    if old_result != track_result:
        completed_releases = list(filter(lambda release: release['status'] == "completed", track_result['releases']))
        if len(completed_releases) == 2:
            track_result['releases'].remove(completed_releases[1])

        print("Updating status: ", track_result)
        service.edits().tracks().update(
                    editId=edit_id,
                    track=TRACK,
                    packageName=PACKAGE_NAME,
                    body=track_result).execute()
        commit_request = service.edits().commit(editId=edit_id, packageName=PACKAGE_NAME).execute()
        print('Edit ', commit_request['id'], ' has been committed')    


  except AccessTokenRefreshError:
      raise SystemExit('The credentials have been revoked or expired, please re-run the application to re-authorize')

if __name__ == '__main__':
  main()

In order to run this step, you need:

Get a Google Developer Service JSON key credentials file. If you have being using some automation tools like Fastlane for uploading the APK to the GooglePlay, you have this already. Otherwise, follow the instructions from Fastlane Supply setup
Install pipenv or some dependency manager for python since the script uses google-api-python-client and oauth2client. You could get them by running:

pipenv install google-api-python-client                            
pipenv install oauth2client

Run the script: pipenv run rollout_update.py <your_package> <json_credential_path>

The script will do the following:

Create a new Google Edit
Fetch the production track release info
For each release, if it has a rollout in progress, then it increases the rollout percentage to the next "step", where steps are: 2%, 5%, 10%, 20%, 50%, 100%.
If changes performed, then commit the Edit

Connecting the CI

So now that we have the script to increase the rollout, all we need is to schedule it. In our case, we are using Bitrise, so we decided to schedule a workflow that runs the script every night. We even created a Bitrise step in case you want to use it that handles the dependencies and running the script.

  update_rollout:
    steps:
    - git::https://github.com/angelolloqui/bitrise-step-google-play-rollout-update.git@master:
        inputs:
        - package_name: com.playtomic
        - service_account_json_key_path: "$BITRISEIO_BITRISEIO_GOOGLEPLAY_SERVICE_ACCOUNT_JSON_URL"

Note: Your credentials file should be stored somewhere secured, like the Generic File Sorage of Bitrise

Halting a failing release?

If a release goes wrong, all you need to do is to go to the Google Dashboard and halt the release as you would normally do with a manually controlled phased release. The script will simply detect the release is halted and will just ignore it.

What about Hotfixes?

Well, the script makes no assumption on the type of build or release, so it will basically just work for any release, including hofixes. However, normally in hotfix builds, since they tend to be critical (otherwise we would not make a hotfix but wait for next week build) we normally deploy it to 100% of the user base, so we do not really need this step to run.

Keyboard observer in Android with LiveData

Angel G. Olloqui — Mon, 23 Mar 2020 09:52:41 +0000

It is very common in mobile apps to need to update UI when keyboard is shown or dismissed. It might be to make some extra space in the screen, to scroll a list to a particular position or just to show some hints to the user while typing. Nevertheless, no matter what your reason is, there is no easy way to detect keyboard opening or closing in Android. Let's explore some ideas:

Option 1: Focus listener ❌

A first approach would be to detect a focus changes on a particular EditText. Code looks like:

editText.setOnFocusChangeListener { _, hasFocus ->
    if (hasFocus) {
        keyboardOpen()
    } else {
        keyboardClosed()
    }
}

However, this solution does not solve the problem completely because when the keyboard is displayed (and field has focus), if the user presses the phone's back button, then the keyboard is dismissed but the focus remains in the EditText. You may think that you can solve this by overriding and detecting onKeyDown or onBackPressed on your activity, but in fact the events are not sent to your activity and there is no way to either detect the dismissal or to force the EditText to lose the focus with it.

Option 2: ViewTree listener ⚠️

A second approach would be add a global view tree layout listener, so every time you have a layout change then you can compute the height difference between your activity root view and the visible display frame for it. Code looks like:

val globalLayoutListener = ViewTreeObserver.OnGlobalLayoutListener {
    val displayRect = Rect().apply { contentView.getWindowVisibleDisplayFrame(this) }
    val keypadHeight = contentView.rootView.height - displayRect.bottom
    if (keypadHeight > minKeyboardHeight) {
        keyboardOpen()
    } else {
        keyboardClosed()
    }
}
contentView.viewTreeObserver.addOnGlobalLayoutListener(globalLayoutListener)

Althought this solution works, it is quite cumbersome and leaves up to the developer big responsibilities like removing the observer when fragment/activity is destroyed. Besides, if you need to do this in many different views, you will end up with a lot of repetition of code that is not trivial. Lastly, the global layout listener will be fired multiples times, so your keyboardOpen and keyboardClosed methods will be fired lots of times with no need.

Solution: LiveData + ViewTree listener ✅

If we iterate on Option 2, we can see that the layout listener can in fact be encapsulated in a component. If we extend that idea, and we make use of LiveData, we can come with a very elegant solution.

Create a small behavior class encapsulating the logic in a LiveData subclass

open class KeyboardTriggerBehavior(activity: Activity, val minKeyboardHeight: Int = 0) : LiveData<KeyboardTriggerBehavior.Status>() {
    enum class Status {
        OPEN, CLOSED
    }

    val contentView = activity.findViewById<View>(android.R.id.content)

    val globalLayoutListener = ViewTreeObserver.OnGlobalLayoutListener {
        val displayRect = Rect().apply { contentView.getWindowVisibleDisplayFrame(this) }
        val keypadHeight = contentView.rootView.height - displayRect.bottom
        if (keypadHeight > minKeyboardHeight) {
            setDistinctValue(Status.OPEN)
        } else {
            setDistinctValue(Status.CLOSED)
        }
    }

    override fun observe(owner: LifecycleOwner, observer: Observer<in Status>) {
        super.observe(owner, observer)
        observersUpdated()
    }

    override fun observeForever(observer: Observer<in Status>) {
        super.observeForever(observer)
        observersUpdated()
    }

    override fun removeObservers(owner: LifecycleOwner) {
        super.removeObservers(owner)
        observersUpdated()
    }

    override fun removeObserver(observer: Observer<in Status>) {
        super.removeObserver(observer)
        observersUpdated()
    }

    private fun setDistinctValue(newValue: KeyboardTriggerBehavior.Status) {
        if (value != newValue) {
            value = newValue
        }
    }

    private fun observersUpdated() {
        if (hasObservers()) {
            contentView.viewTreeObserver.addOnGlobalLayoutListener(globalLayoutListener)
        } else {
            contentView.viewTreeObserver.removeOnGlobalLayoutListener(globalLayoutListener)
        }
    }
}

And then use it everywhere just like:

    // Some Fragment, but it works equally on an activity
    private var keyboardTriggerBehavior: KeyboardTriggerBehavior? = null
    ...
    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        val activity = this.activity ?: return
        keyboardTriggerBehavior = KeyboardTriggerBehavior(activity).apply {
            observe(viewLifecycleOwner, Observer {
                when (it) {
                    KeyboardTriggerBehavior.Status.OPEN -> keyboardOpen()
                    KeyboardTriggerBehavior.Status.CLOSED -> keyboardClosed()
                }
            })
        }
    }

There are a number of benefits of this solution:

It is highly reusable, you can include this in any of your views very easily
It automatically detects the lifecycle events thanks to the usage of LiveData, which means that it is secure to use since it will remove listeners automatically when your fragment/activity is destroyed
It behaves like any other observable of your ViewModels, and it can even be passed down to the view's databinding
It will just fire updates when there is a keyboard state change and not when any layout happens.

We have even added a minKeyboardHeight property in case you need to use this in a splitted view.

Playtomic's chat solution with Firebase Realtime DB

Angel G. Olloqui — Mon, 24 Jun 2019 09:45:08 +0000

A few weeks ago we posted a question in our Playtomic dev blog and our developer network asking for chat solutions. Comments were broad, and we finally opted for a combination of Firebase + MessageKit/ChatKit. But let me make a quick recap of the different solutions available for each of the components (backend + apps):

Existing solutions

Backend

Chat specialized backends

Products like Twilio, Sendbird or Pusher offer a chat based API and set of libraries to handle the chat connection, messages, online presence, etc.

Synched Cloud Databases

In parallel to chat backend solutions there are also some general purpose online databases with real time synching that allow you to implement any feature, including chats, with your own data model. Some examples are Firebase Realtime DB, Firestore, Realm Platform or AppSync

Own Service

You can always create your own chat server infrastructure using some real time transport technology such us WebSockets or XMPP.

Frontend / Mobile apps:

Open source UI components

You can use existing chat libraries for your UI instead of implementing your own. Two of the most popular and mature options are MessageKit for iOS and ChatKit for Android. They provide most UI components you would expect from a chat.

Own UI

Chat screens are, in general, not that complex from a UI perspective. As such, you could decide to implement your own views and handle text messages, images, locations,... yourself.

Full product

Lastly, there are also some products like ChatSDK, Cometchat, Chat21 or Chatcamp.io that provide a fully featured solution, from backend to frontend. They normally provide a mobile SDK with full UI ready to be added to your project in a very quick and easy way, together with some degree of UI customization and public APIs to manage the data.

Solution choice for Playtomic

For Playtomic, we wanted a solution that fulfills our needs:

Pricing: Due to the nature of our app we have many thousands of “connected” users, but where most of them are just using the app with a different purpose than chatting. However, since every app user can potentially have unread messages, they will all need to connect to check for unreads, even if in the vast moyority of them will have none. Therefore, we need a solution where we can have thousands of readers per month with a very small amount of writers in a price efficient way, preferably within a free tier.
Customization: We started the chat as an experiment, but we foresee a future where the chat can enable much more complex interactions that just writing/reading messages. For example, after a match, we could use the chat to suggest users to rematch, rate the other players, fill in the results, suggest similar open matches… Choosing a solution that enables us to customize messages and program rich bot interactions will be important if the experiment succeeds
Complexity: As mentioned, our chat feature is an experiment, a new channel for players to communicate with each other within the app, but it is far from our product’s core. For that reason, it was important to have an MVP in reasonable development time (1 sprint / 2 weeks) and with low operational cost.

We started exploring ChatSDK as it provided what it looked like a good balance between pricing (Firebase Realtime DB is used as backed, which has a decent free tier), customization (being open source and a general purpose DB on backend allows for any change needed) and complexity (full product, backend and frontend, should be quick to integrate). However, after a couple of days integrating it in our existing app we found some issues (crashes, bad designed code, difficulties customizing appearance, platform differences,...) which made us pivot to what it is now our current setup: Firebase Realtime DB + MessageKit / ChatKit

Data Model + Firebase Functions

When using Firebase RealtimeDB (RTDB) you have to model your data with some constraints in mind:

Access control: RTDB provides some granular access control rules, where you can specify restrictions using user’s auth information, accessing fields on child nodes, parents or siblings, etc. However, note that it does not work from bottom -> top but the other way top -> bottom. This means that if you have a rule granting access to, for example, /threads/ to user A, even if you make another rule inside /thread/thread-1 denying it, the user A will still be able to fetch it since it has access to the parent node. This restriction is especially important when you consider the data model, since it forces you to split your data in different collections if you want to provide a fine grained access control like private chats while still be able to fetch all public threads for example.
Querying: RTDB has some basic sorting and filtering functions, but very far from what anyone would expect for a database. In particular, you can filter or sort on a concrete value and paginate results with limit options, but you can not make complex queries combining multiple fields or expressions. Similarly to access control, this limitation can be minimized by denormalizing your model into one that already fits your filtering like, for example, creating user indexes, public indexes,...
Data Transfer: One of the most costly mistakes when using RTDB is not caring about transferring. Remember that you can not make complex queries, aggregations, retrieve partial documents or restrict access on a child level. As a result, if you would access to something like /threads to count the amount of existing threads, you would download the whole tree content and therefore consume enormous amounts of data on your clients (which will be later accordingly charged by Firebase). Once again, denormalization is normally the way to go to create partial documents, precalculated aggregations, user indexes, etc.

We based our data model on the one provided by ChatSDK, with a few modifications to solve the restrictions mentioned above. Our final data model looks like:

/devices: Here we store information of push notification tokens per device and per user
/messages/{threadId}: We have our messages in its own index to allow low level access control per thread and to permit consumption of threads without downloading all the message list (to show user’s thread list UI)
/threads: Here we store threads metadata like the name, users, last message,... It is our “main” document for threads and used by the denormalization processes. It has restricted access control on a per thread level, and it is the one modified by our backend when chat updates like new players joining a match happens.
/user-threads/{userId}: This is our main entry point for all our users. It consists of a denormalized index of the /threads collection containing only those that are “viewable” by the user. Each time there is a new thread or an update on an existing thread under /threads, there is a denormalization function making a “copy” on all participants indexes.
/users/{userId}: In a similar way than user-threads, this denormalized index contains information like the unread count or the user’s online presence. Once again, when there is a new message on the /messages collection, all users in the affected thread get their unread count increased (unless they are online and viewing the thread). This allows us to read this only document to fetch chat status when the application starts, and configure the unread badge on the app tabbar with the proper number without consulting the whole user thread list.

For the bookkeeping of all the denormalization mentioned above, Firebase provides Functions, which are basically javascript functions that can get triggered in different circumstances (like insert/delete/update of RTDB nodes) and perform actions like sending push notifications, modifying data,.... In particular, we have the following functions:

Create /messages/{threadId}/{messageId}: Triggered when new messages are written, this function is in charge of sending push notifications, copying this last message into the thread’s last message denormalization, make the denormalized copy on user-thread index and increase user aggregations for unread counts.
Create /threads/{threadId}/users/{userId}: Triggered when a new user joins a thread, it creates a denormalized copy on the user-threads index
Delete /threads/{threadId}/users/{userId}: Triggered when a user leaves a thread, it deletes any denormalized copy from the user-threads index and refreshes the user unread count accordingly.

Analytics

After a few weeks since going live with the chat, let's quickly explore some usage analytics for the last 30 days:

Number of users

~3000 chat openings from match detail, where approximately 30% are not players (visitors)
~2400 chat openings from profile

Number of messages:

~2700 total messages,
~90 message per day average
Peaks of almost 250 messages per day.
Increasing trend

Number of chats:

436 chats with messages.
70 chats having at least 10 messages
45 chats representing around half of the total messages sent.

Firebase consumption

After explaining the current chat usage and the denormalized data model used to reduce the Firebase bill, let's take a look on some of the most critical quotas for the last 30 days to see how we made so far:

Function invocations

With a free quota of 125K/month and a price of 0.4$ per million, we are using around 5% of it and very far from paying any noticeable cost from this concept.

RTDB storage

This is probably one of the most critical, since the amount of space used can only grow with time (unless we delete old chats) and it increases faster than chat usage due to denormalization. Our current use is about 8MB, with a free tier of 1GB and 1$ per GB extra. So, right now, we are below 1% of usage, with an increasing ratio of around 5MB a month, very far as well from exceeding quota at this time but probably out of quota in a not so distant future if the chat usage continues its growing trend.

RTDB transfer

Download traffic is the most worrying quota and by far the most abused one by other projects, in some cases causing billings of many thousands dollars per month. However, in our case, with all the denormalization we made, we have used 800Mb out of the 10Gb/month free tier. This leaves us with room to grow about 10x within the free quota and with a potential cost of 1$/GB after that limit. We expect to exceed the quota in a future, but hopefully keeping the cost relatively low.

Conclusion

So far we are very satisfied with the results. The combination of Firebase RTDB + open source UI kits, allowed us to build a customizable solution within our 2 week development timebox. Besides, chats are behaving nicely so far, with low latency and offline support, while we are still pretty far from leaving the free tier. Of course, we did not implement many of the advanced options that other chats provide, things like read-checks, mute chat, typing indicators,... will have to wait, but we have the basis ready to continue development if wanted.

Chances are in the future we will run into other issues due to denormalization, but so far we have a decent solution in the hands of our users while we explore if the expirement is worth to continue investing on it (as it looks like so far based on usage).

Playtomic's Shared Architecture using Swift and Kotlin

Angel G. Olloqui — Mon, 13 Aug 2018 14:13:10 +0000

Choosing the technology stack is one of the first and most important decisions when starting any project from scratch. At Playtomic, we knew that we wanted to pick a stack for the mobile apps that would allow us to deliver the best possible experience given our limited resources available.

Mobile stacks range over a plethora of alternatives:

Web technologies

Solutions like responsive web apps or progressive web apps allow you to leverage your web frontend experience while having a single project for all. Some native capabilities can not be used but for most apps it would be enough. Distribution is through web browsers and not inside an App Store which may be an advantage or disadvantage depending on your case

Hybrid

Next step on the road to native you can choose to use an hybrid framework like Phonegap/Cordoba, which also uses web technologies but get wrapped into an app bundle, offering extra capabilities and an improved UX over pure web.

Multiplatform Solutions

There are several multiplatform solutions like Xamarin, ReactNative or the newer Flutter. They all have their own selling points and disadvantages, but in general they offer a unified solution to build native apps by using a single language and, to some degree, a single UI layer with custom components, sharing most of the code across the platforms while delivering a good UX, very close (if not the same) than the one delivered by native apps.

Native

The industry standard, and the one that brings the best UX is also the one that requires the most resources. Building native means building an app per platform, each one with its own language, set of tools, libraries and frameworks.

Our dilemma

Without getting into too much detail about each one and our analysis, we knew that we wanted Playtomic to be a leader in the sports area, and being a mobile first project we wanted it to bring the best possible experience to our end users.

We also knew that once picked, that technology stack would be our one and only one stack for long since we do not have the resource power to maintain a “Frankenstein app” built in parts with different stacks or Big Bang refactors to completely migrate from one to another. We wanted “the stack” to be production ready and with enough community and maturity to have the “certainty” that it will be supported for our project’s life.

That basically left us with 3 candidates: Xamarin, ReactNative and Native; and from those first two we were much more appealed by React than Xamarin because of its programming model, the possibilities to share code with a future web frontend and the amazing community and tooling.

On the other hand, when selecting a solution, you also have to consider the team you have. In our case, we were expert native developers, with experience in both platforms (Android and iOS) and with little to no experience in React or other multiplatform stacks. Besides, at that moment, there was no web frontend developer or anyone within the company with enough React experience to coach the mobile team during the learning curve.

Having all that in mind, our best fit was native. It delivers almost everything we wanted (best UX, industry standard, maturity, long term vision, great tools, great community,...) except for one important aspect: cost

As explained before, going native would mean to build 2 apps (iOS/Android), which has an extra cost compared to the single app of multiplatform solutions. But how much? Let’s try to put very rough numbers with an example (note that these are not real numbers, they are just an estimate based on our own previous experience, don’t take them too seriously but just as an illustration):

Native: Let’s say you are building a feature that takes you 100h on iOS. Then, porting it to Android would take around 80h extra (not 100 because there is always knowledge that can be “ported” from the first platform). A total of 180h
Multiplatform: The same feature would take you around 120h, depending on how much you can reuse and the technology used. It is not write once run everywhere but close enough to add only a small percentage of extra work over a single platform.

So, roughly 180h vs 120h, or in other words around 50% extra time to go native. That is quite a lot! Especially for a small team like ours.

So, our next question was: can we find a way of building a native app maximizing reusability across platforms and keeping the cost down, close to the one delivered by multiplatform solutions? And if so, will it take us less than 1-2 months work of setup? (That was the time we had until the product and design teams would start delivering well defined features to build)

I had participated in the past of some very small projects (Proof Of Concepts and a minor library) using this approach with excellent results. But building a full app is a completely different challenge, especially when the application grows.

Shared foundations

So, we started building with one objective in mind: reusability across native platforms

What we did was to split the app in 3 main parts for both platforms:

Anemone SDK: framework used to connect to our backend and provide persistence. It provides Model, Service and some utilities.
Playtomic UI: framework with visual components like custom textfields, input validators, generic datasources/adapters, animations, ...
Application code: where our modules and features are built. It includes and uses the former two.

We made sure that both frameworks offered the same public API (different implementations) and we also built a few facades over concepts that would be used across the app and that were provided differently on each platform, keeping the same API again. To name a few:

Promise (iOS Android)
HttpClient (iOS Android)
JSONObject (iOS Android)
NavigationManager (iOS Android)
LocationManager (iOS Android)
...

(You can check all code in these repos: Swift Kotlin)

We also picked the combination of Swift/Kotlin because of their enormous similarities and we used SwiftKotlin to minimize the time needed to transpile code from iOS to Android.

Finally, we added a few extensions over foundation objects to provide some of the missing methods on one or the other language (ex: compactMap, flatMap, let,...)

Examples

Let me go quickly through an example, in this case a Login view and presenter in Swift and Kotlin

See in the above screenshot how with just a minor fix on the Kotlin code we get a fully working Android version of a Presenter by transpiling the iOS one in about 15 seconds.

LoginPresenter

Swift

class LoginPresenter: Presenter<ILoginView> {
    let coordinator: IAuthCoordinator
    let appEventManager: IAppEventManager
    let messageBarManager: IMessageBarManager
    let navigationManager: INavigationManager
    let authenticationService: IAuthenticationService    

    init(coordinator: IAuthCoordinator,
         appEventManager: IAppEventManager,
         messageBarManager: IMessageBarManager,
         navigationManager: INavigationManager,
         authenticationService: IAuthenticationService) {
        self.coordinator = coordinator
        self.appEventManager = appEventManager
        self.messageBarManager = messageBarManager
        self.navigationManager = navigationManager
        self.authenticationService = authenticationService
    }

    override func viewPresented() {
        super.viewPresented()
        view?.setIsLoading(false)
        if authenticationService.isLoggedIn() {
            skipLogin()
        }
    }

    func skipLogin() {
        self.view.let { self.navigationManager.dismiss(view: $0, animated: true) }
    }

    func login(email: String, password: String) {
        view?.setIsLoading(true)
        authenticationService.login(user: email, password: password).then { [weak self] _ in
            guard let `self` = self else { return }
            self.view.let { self.navigationManager.dismiss(view: $0, animated: true) }
            self.appEventManager.sendEvent(AppEvent.loginWithCredentials(success: true))
        }.always { [weak self] in
            self?.view?.setIsLoading(false)
        }.catchError { [weak self] (error) in
            self?.messageBarManager.showError(error: error)
            self?.appEventManager.sendEvent(AppEvent.loginWithCredentials(success: false))
        }
    }

    func rememberPassword() {
        navigationManager.show(coordinator.requestPasswordIntent(), animation: NavigationAnimation.push)
    }

}

Kotlin

class LoginPresenter(
        private val coordinator: IAuthCoordinator,
        private val appEventManager: IAppEventManager,
        private val messageBarManager: IMessageBarManager,
        private val navigationManager: INavigationManager,
        private val authenticationService: IAuthenticationService)
    : Presenter<ILoginView>() {

    override fun viewPresented() {
        super.viewPresented()
        view?.setIsLoading(false)
        if (authenticationService.isLoggedIn()) {
            skipLogin()
        }
    }

    fun skipLogin() {
        this.view?.let { this.navigationManager.dismiss(view = it, animated = true) }
    }

    fun login(email: String, password: String) {
        view?.setIsLoading(true)
        authenticationService.login(email, password)
                .then {
                    this.view?.let { this.navigationManager.dismiss(view = it, animated = true) }
                    appEventManager.sendEvent(AppEvent.loginWithCredentials(success = true))
                }
                .always { 
                    view?.setIsLoading(false) 
                }
                .catchError { error ->
                    messageBarManager.showError(error = error)
                    appEventManager.sendEvent(AppEvent.loginWithCredentials(success = false))
                }
    }

    fun rememberPassword() {
        navigationManager.show(coordinator.requestPasswordIntent(), animation = NavigationAnimation.push)
    }

}

String similarity: 73.59%

LoginView

class LoginViewController: PresenterViewController<LoginPresenter> {
    @IBOutlet weak var usernameTextField: PlaytomicTextField!
    @IBOutlet weak var passwordTextField: PlaytomicTextField!
    @IBOutlet weak var loginButton: UIButton!
    @IBOutlet weak var dismissButton: UIButton!
    @IBOutlet weak var loadingIndicator: UIActivityIndicatorView!

    override func viewDidLoad() {
        super.viewDidLoad()

        usernameTextField.configure(
            inputType: .email,
            labelText: R.string.localizable.auth_login_user_field(),
            errorMessage: R.string.localizable.auth_login_user_error(),
            validators: [
                TextFieldEmailValidatorBehavior(textField: usernameTextField.textField)
            ],
            editTextDidChangeCallback: { [weak self] in self?.reloadLoginButtonState() }
        )

        passwordTextField.configure(
            inputType: .password,
            labelText: R.string.localizable.auth_login_password_field(),
            errorMessage: R.string.localizable.auth_login_password_error(),
            validators: [
                TextFieldLengthValidatorBehavior(textField: passwordTextField.textField, minLength: 5, maxLength: nil)
            ],
            editTextDidChangeCallback: { [weak self] in self?.reloadLoginButtonState() }
        )
        reloadLoginButtonState()
    }

    @IBAction func login() {
        view.endEditing(true)
        presenter.login(email: usernameTextField.text, password: passwordTextField.text)
    }

    @IBAction func skipLogin() {
        presenter.skipLogin()
    }

    @IBAction func rememberPassword() {
        presenter.rememberPassword()
    }

    func reloadLoginButtonState() {
        let fieldsValid = usernameTextField.isValid && passwordTextField.isValid
        let loading = loadingIndicator.isAnimating
        loginButton.isEnabled = fieldsValid && !loading
    }

    // ****  View Interface  ****

    func setIsLoading(loading: Bool) {
        if newValue {
            loadingIndicator.startAnimating()
        } else {
            loadingIndicator.stopAnimating()
        }
        reloadLoginButtonState()
    }

}

class LoginFragment : PresenterFragment<LoginPresenter>(R.layout.login_fragment), ILoginView {

    @BindView(R.id.username_edit_text_custom)
    lateinit var usernameCustomEditText: PlaytomicTextField

    @BindView(R.id.password_edit_text_custom)
    lateinit var passwordCustomEditText: PlaytomicTextField

    @BindView(R.id.login_button)
    lateinit var loginButton: Button

    @BindView(R.id.toolbar_back_button)
    lateinit var dismissButton: ImageButton

    @BindView(R.id.loading_indicator)
    lateinit var loadingIndicator: ProgressBar

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        usernameCustomEditText.configure(
                inputType = PlaytomicTextField.InputType.email,
                labelText = R.string.auth_login_user_field,
                errorMessage = R.string.auth_login_user_error,
                validators = listOf(
                        TextFieldEmailValidatorBehavior(usernameCustomEditText.editText)
                ),
                editTextDidChangeCallback = ::reloadLoginButtonState
        )
        usernameCustomEditText.nextTextField = passwordCustomEditText

        passwordCustomEditText.configure(
                inputType = PlaytomicTextField.InputType.password,
                labelText = R.string.auth_login_password_field,
                errorMessage = R.string.auth_login_password_error,
                validators = listOf(
                        TextFieldLengthValidatorBehavior(passwordCustomEditText.editText, 5, null)
                ),
                editTextDidChangeCallback = ::reloadLoginButtonState
        )
        reloadLoginButtonState()
    }

    @OnClick(R.id.login_button)
    internal fun login() {
        hideKeyboard()
        presenter.login(email = usernameCustomEditText.text, password = passwordCustomEditText.text)
    }

    @OnClick(R.id.auth_login_forget_password_button)
    internal fun rememberPassword() {
        presenter.rememberPassword()
    }

    private fun reloadLoginButtonState() {
        val fieldsValid = usernameCustomEditText.isValid && passwordCustomEditText.isValid
        val loading = loadingIndicator.visibility == View.VISIBLE
        loginButton.isEnabled = fieldsValid && !loading
    }

    // ****  View Interface  ****

    override fun setIsLoading(loading: Boolean) {
        loadingIndicator.visibility = if (loading) View.VISIBLE else View.GONE
        reloadLoginButtonState()
    }

}

String similarity: 70.8%

As you can see, code is basically the same except for some language differences (constructors, keywords,...) that can be quickly transpiled. Moreover, by using PlaytomicUI components and some of our extensions, code is similar even on the View layer. The main work on this part corresponds to laying out elements in Interface Builder (iOS) or in layout XMLs (Android).

An interesting note to make here is that we could have decided to write the Views in code or with tools like Layout. That would make possible to reuse much more here as well, but we intentionally chose not to because we wanted to keep this part (the one the user actually sees and experiences) as standard as possible. This also allows us to use and follow platform components and conventions when desired and the de facto developer tools available, hence keeping a moderate learning curve and taking advantage to a full extent of our native development expertise.

The good, the bad and the ugly

After 1.5 years working with the explained Shared Architecture, conventions and tools, we have a pretty solid view of what’s working for us and what is not working that well. Let me try to make an introspection:

The good

Team unification: there is no Android/iOS team distinction because the same developer always transpiles his work to the other platform. This results in extreme union, platform parity and less disputes/blockages
Team performance: developing app code is much faster than writing 2 platforms independently. It typically takes just a few minutes to transpile Presenters, Interactors, Coordinators, Models and Services. XML and Xib files takes the rest of the time, and every now and then some code in managers. In average, we take about 30% extra time to convert from one to the other platform, depending on the amount and complexity of the views involved, pretty close to multiplatform solutions.
Fully native UX: Visual components and app performance is the same than any other native app. Besides, there is no extra penalty on app size nor app launch time like in multiplatform solutions.
Long term vision: we use the facto tools, frameworks and languages on each platform, and we have no important dependencies. We can have the certainty that code will be valid for many years, even if at some point team grows and we stop sharing code they will still be valid standard native projects independently.
Good abstractions and code quality: The fact that we want to reuse as much code as possible forces developers to think very carefully the abstractions they want to build. It encourages for proper separation of concerns, single responsibility classes, more testing (to verify the transpilation), etc. In fact I would even say that code reviews are also more effective as you can compare the PR side by side with the counterpart and detect issues on a higher level. Quality is not just desirable but it is also perceived as an actual productivity boost from day 1.
Reduced project’s cognitive load: Having 1 code base makes understanding the project and remembering the internal details much easier.

The bad

Extra architecture work: it is no secret that building these shared abstractions and extensions take time. In our case we dedicated about 1 month to architectural foundations, and since then we have had to make some changes and additions every now and then. The total overhead is difficult to calculate, but it is noticeable especially at the beginning.
Hidden bugs from language differences: transpilation works great, most of the time 💥. However, during these 18 months working on it, we have encountered 3 or 4 times bugs derived from language differences that were unexpected. Especially important is the Value type (struct) in Swift that has no counterpart in Kotlin or the sort in place of arrays in Kotlin. These differences impose restrictions and are a source of bugs if not considered properly.
Maximum common factor of language features: in parallel to the previous bullet, having to share code imposes restrictions on the way you use a language (or more transpilation work is required). As a result, we tend to write code using the maximum common factor of language features. A few examples of limitations on Swift are value types and protocol extensions, while in Kotlin the usage of decorators or default parameters in interfaces.
View layer needs work per platform: writing views require specific work per platform. That has an impact on development time, testing and bug fixing that would not ocurr that much with multiplatform solutions with shared UI.
Learning curve: all the architectural components and code conventions that we use are specific from this project and therefore require some learning. Nevertheless, to be fair all projects have their own internal conventions and architecture design, so at least having the same across both platforms means that there is only 1 curve to pass and not 2.

The ugly

Hybrid conventions: Kotlin and Swift are very similar but they use different naming conventions. For example, in Kotlin/Java constants are written in upper case while in Swift they aren’t. Or the classical I prefix so common in Java does not exist in Swift (the closest would be to suffix Protocol to the name). As a result, when sharing code you have to either come with a mix of conventions or penalize the transpilation process with more manual edition to adapt from one to the other. We started with conventions per platform and we are gradually moving into a single convention that feels to us like the best of both worlds and which is becoming our de facto mobile team convention (but it would look “ugly” to external developers)
Replicate changes manually: transpilation works great when building new features because you can copy&paste the full transpiled code. However, when maintaining code, it is up to the developer to remember to apply the same change made on platform A into platform B. As a result, we have sometimes forgotten to replicate, resulting in some inconsistencies on app behavior. We are controlling that through PR, forcing both platforms to have the same kind of changes and reviewing them in parallel, but there is still the case for human error.
Team scaling: having such a small team helps when using this approach since it requires lots of communication between members. We are not sure how this would scale with more developers, but we suspect it won’t the day we have 6+ people or so. Besides, we are “forced” to hire (or teach) multiplatform experts as long as we want to keep sharing code efficiently.

Overall, when looking back, we feel the decision has been the correct one for our team. That does not mean that using React would have been a mistake (probably not), but we are very satisfied with the results we are getting. Sure, we run into some issues every now and then, and we have had to invest a couple of months on making the abstractions (this time would have gone to learning React anyway), but we have now the best UX possible with a very decent development speed. Moreover, we are not dependent on some third party framework or tool (even SwiftKotlin could be removed and just transpile code manually, which is not that bad anyway) what gives us long term confidence, and we are free to chose the application architecture we prefer per module (MVP, MVVM, VIPER, REDUX,...). We can also leverage all of the native goodies the instant they are announced and we can use the team knowledge to full extent.

String similarity calculated with Tools4Noobs