Skip to content
Abdullah Ghonaiem
All projects

Mobile Applications

Masaha

مساحة

Hybrid iOS and Android development for a tailoring app with AI-assisted body measurement.

Company
Fifty Studios Holding Company
My role
Mobile Software Engineer
Status
In production
Key result
~5,000 app users
  • Capacitor
  • Swift
  • Java
  • MirrorSize
  • Google ML Kit
  • OneSignal

Overview

Masaha (مساحة) is a tailoring app for iOS and Android with approximately 5,000 users. Customers order tailored clothing from their phone, and instead of visiting a tailor to be measured, they can be measured by the app.

Measurement is the product’s distinctive capability: the app guides the customer through a camera capture and returns body measurements using MirrorSize, a third-party AI measurement service, with Google ML Kit helping to guide the capture on the device.

Problem and context

Masaha is a hybrid app. The storefront is web content inside a native shell, while camera capture, notifications, and sign-in state live in native iOS and Android code. A fault can sit in the web layer, the native layer, or the seam between them, and it often looks the same from the outside.

When I joined, the production apps had problems of exactly that kind: crashes at launch on Android, pages that would not respond on iOS, unreliable notification links, and a Google Play rejection to resolve.

My contributions

Designed and developed

My own work

  • A rewritten push notification layer on both platforms, covering permission timing, cold-start links, and login identity.

Maintained and improved

Production systems I kept healthy

  • Diagnosed and fixed a critical startup crash on Android.
  • Fixed iOS WebView loading and first-tap problems.
  • Resolved Google Play compliance issues, including removing broad storage permissions.
  • Fixed the Android file chooser, added baseline profiles, and managed releases on both stores.

Done with the team

Shared work

  • Worked on the MirrorSize integration with the team: the flow that connects the app’s guided capture to the measurement service.
  • Deep-link handling between the web layer and the native apps.

Built by others

Not my work

  • MirrorSize’s measurement AI is a third-party service. I did not develop the underlying model.
  • The original application and its storefront, built by the team before my involvement.

Technical architecture

Where my work landed

Conceptual diagram

  • Measurement

    • MirrorSize measurement AI (third party) (predates my work)
    • MirrorSize integration in the app (my work)
    • Guided camera capture (ML Kit) (predates my work)

  • Hybrid layer

    • Web storefront (predates my work)
    • iOS WebView loading (my work)
    • Deep links (my work)

  • Native layer

    • Android startup path (my work)
    • Push notifications (OneSignal) (my work)
    • Android file chooser (my work)

  • Release

    • Google Play compliance (my work)
    • iOS & Android releases (my work)
The app’s main layers. Highlighted items are areas I worked on; the rest is existing or third-party.
A web storefront in a native shell
The shopping experience is web content shown in a WebView. The native layer adds what the web cannot do well: camera capture, push notifications, and secure storage of sign-in state.
Native capture, external measurement
Capture is fully native on both platforms, with on-device pose detection guiding the customer into position. The captured images go to MirrorSize, which returns the measurements.
A bridge between web and native
The web layer and native code share sign-in state, so a customer who logs in on the storefront is recognised by the native features and by the notification service.
Notifications and links
OneSignal delivers push notifications. A tapped notification is routed into the app’s own WebView, including when the app was closed at the time.

Engineering challenges

  1. A crash before the first screen

    Challenge
    Some Android users could not open the app at all. At launch, the sign-in check could refresh an expired session over the network on the main thread, and the system killed the app.
    Approach
    I moved the check to a background thread, kept the splash screen visible until it resolved, and routed to the correct screen back on the UI thread. Session cleanup was made to run even when the refresh failed.
    Technology
    • Android
    • Java
    • SplashScreen API
    • Threading
    Outcome
    The launch path no longer blocks on the network, and the startup crash was resolved.

  2. An iOS page that ignored the first tap

    Challenge
    On iOS, content appeared only after a second tap and the first load was slow. Three separate causes were stacked: a global right-to-left setting reached the WebView’s internals, the WebView was created at zero size, and session cookies were restored after the first request.
    Approach
    I scoped the right-to-left setting to the native controls that needed it, created the WebView at full screen size, and restored cookies before loading. A small injected script forces a layout pass after load for content that arrives later.
    Technology
    • iOS
    • Swift
    • WKWebView
    • Injected scripts
    Outcome
    Pages render and respond on first load, with the customer already signed in.

  3. Notifications that land in the right place

    Challenge
    Tapped notifications opened in the browser instead of the app, taps on a closed app were lost, and the permission prompt appeared at launch before the customer had any reason to accept.
    Approach
    I rewrote the notification layer. Taps are captured as a pending destination that the WebView opens when it is ready. Permission is requested only after the customer opts in on the site, with a path to system settings after an earlier refusal.
    Technology
    • OneSignal
    • Android
    • iOS
    • Deep links
    Outcome
    Notification taps open the intended page inside the app, from any app state.

  4. Staying on the store

    Challenge
    Google Play rejected the app over permissions broader than it needed, which blocks every future update until it is fixed.
    Approach
    I removed the broad storage and media permissions, repaired the file chooser that had depended on them, and shipped the change through a normal release cycle.
    Technology
    • Google Play policy
    • Android permissions
    • Release management
    Outcome
    The compliance issue was resolved and releases continued.

Results and impact

App users
~5,000
Approximate.
  • Critical Android startup crash resolved
  • iOS WebView loading and first-tap issues resolved
  • Push notification handling on both platforms
  • Google Play compliance issues addressed

Visuals

No product screenshots published

App screenshots will be added once approved for publication. The cover and the architecture diagram on this page are conceptual illustrations.