Fern grove studio

Unfurled on iOS and Android

JO FERNS LTD makes mobile applications, and has done so for years. We take a product through behavior, design, build, testing, release, and the updates that follow. Every product is made for both platforms. One plan puts down roots on iPhone and on Android, and we stay while those roots hold.

Platforms

Two shores, one root

An iPhone and an Android phone do not want the same gesture, the same type, or the same permission sheet. We treat them as two shores of one root. The plan — what the app does, what it refuses, how a task ends — is shared. The surface follows the platform: navigation, the back gesture, notification permission, and the way type sits on the glass.

A first release is a date, not a farewell. Operating systems move. A control that was clear in spring can feel cramped by autumn. A defect can hide in a path almost no one takes, until someone does. Updates are part of the job: tested on both platforms, released as a pair, described in plain language. We do not ship one build and treat the other as a later hope.

The frames here are a sketch of that shared plan. They are not a store listing and not a client’s brand. They show the idea we hold while we draw: one scope, two manners, neither of them a photocopy of the other.

Shared plan

iOS

  • Today’s route
  • Shade log
  • Push opt-in
iOS manner. Same scope.

Shared plan

Android

  • Today’s route
  • Shade log
  • Back gesture kept
Android manner. Same scope.

Approach

How a frond opens

A frond does not open all at once. Neither does a careful app. We keep the order visible so a project does not skip from a vague hope to a decorated screen.

  1. Behavior

    Before a layout, we write what a person can start and what the app must finish. We also write what it will not do. A weak network, an interrupted task, and a change of mind halfway through belong in that writing.

  2. Design

    Screens include empty states, errors, and the small motion that shows a change has landed. iOS and Android stay on the table together, so a pattern only one of them can support is questioned before anyone builds it.

  3. Build

    Engineering proceeds against the one plan. Platform edges stay named: share sheets, the keyboard, the back gesture, and the moment a notification asks permission.

  4. Testing

    We test on devices, not only in a simulator window. We look for clipped type, a slow start, a trap, and a path that fails only when a step is skipped.

  5. Release

    Version numbers, store text, and rollout. The listing describes the job of the app. It does not borrow praise the product has not earned, and it does not promise a result the app cannot produce.

  6. Updates

    After release we come back for defects, for new operating-system behavior, and for the next small improvement the plan already implied. A product that ships and vanishes is unfinished.

Count

Numbers you can check

These are facts about how the apps are built. They are not a growth chart. Attribution uses Singular. Push notifications use OneSignal. Nothing in that chain is a path from one user to another.

  • 2 platforms

    iOS and Android, for every product we take on.

  • 1 shared plan

    One scope, two builds, released as a pair.

  • 0 user-to-user data

    People do not send personal data to each other through the app.

  • 1 unique id

    The only identifying item. It serves attribution and push, not a biography.

Sequence

Five turns of the work

A release follows five turns. None of them is a poster. Each one ends with something you can read: a list of actions, a set of screens, a build, a test note, or a version in the stores.

  1. 01

    Sound the ground

    We learn the job in plain language: who it is for, what must happen, and what must never happen.

  2. 02

    Draw the curl

    Interface and states, with iOS and Android both in view, including the empty and the failed.

  3. 03

    Build the stem

    Implementation against the shared plan, platform by platform, with the edges kept explicit.

  4. 04

    Hold it to the light

    Testing on devices, including readable type, a tolerable start, and paths that can be left.

  5. 05

    Let it unfurl

    Release, then the updates that keep the app honest as the system underneath it changes.

Questions

Under the fronds

Do you build every app for both iOS and Android?

Yes. Every product is made for both platforms. We do not ship a single-platform version and call the job done. The plan is shared. Each build follows the habits of its own system.

What can the in-app assistant do?

It can talk with the person using the app. It replies inside the product. What someone writes is used only to answer that person. It is not passed to other users, and it is not saved as a portrait of who they are.

Is the assistant a person, or professional advice?

No. The assistant is software. It is not a human, and it is not professional advice — not legal, medical, financial, or any other licensed kind. If you need a person at the studio, use the email on this site.

Do the apps build a personal profile?

No. There is no profile built from a name, an email address, a phone number, contacts, or precise location. The apps are built to do their job without that record.

What is the unique id for?

It is the only identifying item. Attribution uses it with Singular. Push notifications use it with OneSignal. It is a technical handle for those two roles, not a key to a dossier.

Can people send personal data to each other?

No. The apps are not a channel between people. There is no exchange of personal data from one user to another: no shared inbox, no contact discovery, no hand-off of a name or a number.

How do we reach the studio?

Write by email. The contact page names the developer and opens your own mail app. The privacy note and the terms spell the same facts out in full. The assistant cannot take a letter meant for us.

Assistant

A voice in the app, not a person

Many of the apps include an assistant you can talk to. It answers inside the product. It is software, not a member of the studio on a chat shift, and a reply is not professional advice. A question about the app can get a direct answer. A question that needs a lawyer, a doctor, or another licensed adviser will not be treated as if it had one.

In-app assistant

How do I read this week’s log?

Open Shade log, then this week. I can list the steps. I am not a person, and this is not professional advice.

Do you keep what I type?

Only to answer you. It is not sent to other users, and it does not become a profile.

Software. Not a human. Not professional advice.

Not a human

The voice is the assistant. It is not someone at the studio pretending to type.

Not advice

It does not stand in for a lawyer, a clinician, or any other qualified adviser.

Not shared

What you write is used only to reply to you. Other users do not receive it.

Privacy

What the shade keeps

The apps do their job without a personal profile. No name, email, phone number, contact list, or precise location is gathered to describe a person. Users do not exchange personal data with each other. Attribution uses Singular. Push notifications use OneSignal. The identifying item for both is a unique id, not a biography.

Userno exchangeUser

Mail you send from this website goes to the developer. It is ordinary correspondence. It is not mixed into the app, and it is not handed to other people who use the apps. The privacy note is the full account, including how a change will be posted.

Contact

Send a note into the grove

The developer is JO FERNS LTD. Write directly, or open the contact page and use the form. The form does not store anything here. It opens your mail app with the subject and the message filled in.

[email protected]