Skip to main content

Mobile overview

GreekManage ships native apps for iOS and Android in addition to the web app. The mobile apps are not a separate product — they wrap the same React frontend inside a Capacitor shell, talking to the same Django API. Everything you can do on the web you can also do on the phone. A handful of capabilities, however, are native-only or work differently on the phone, and this page is the consolidated reference for what to expect.

For per-page mobile notes (how a specific dashboard or form behaves on a small screen), every page in For Members, For Chapter Officers, and For Org / National Admins has a "Mobile differences" section near the bottom.

What "mobile" means here​

There are three ways to interact with GreekManage on a phone:

  1. The native iOS app (TestFlight today, App Store distribution planned) — a Capacitor wrapper around the React frontend. Has access to native APIs: biometrics, the keychain, the iOS file picker, the camera.
  2. The native Android app (Google Play Internal Testing today) — the same Capacitor wrapper packaged for Android. Same set of native APIs via Android equivalents.
  3. Mobile web — Safari or Chrome on a phone, hitting the same React frontend that the desktop browser hits. This gets the responsive layout but cannot use any native API.

When this page says "native" it means either iOS or Android in the Capacitor wrapper. When it says "mobile web" it means a browser. The distinction matters for biometrics, the server selector, push notifications, and a few other features that are wrapper-only.

What is different on native vs web​

The biggest practical differences:

Authentication model​

The web app stores its session in an httpOnly cookie. The browser sends the cookie automatically with every request, and the server reads it via the cookie-based JWT authentication path.

The native app cannot use httpOnly cookies the way a browser does. Instead, native sends an Authorization header on every request, signed with X-Client-Type: native. The backend recognises the native client type and returns auth tokens in the response body on sign-in (the web client receives no tokens in the body — only the cookie). This is invisible to the user but matters when debugging "logged in on web, not on phone."

Biometric unlock​

Native apps support Face ID / Touch ID (iOS) and the equivalent Android biometric prompt as an optional unlock layer. This is opt-in: the first time you sign in on a fresh install, the app asks whether to enable biometric unlock for future launches. You can change the setting later from Account settings → Security → Biometric.

If biometric is enabled, the app launches in a locked state and asks for biometric (or PIN/password fallback) before showing your data. Sign out clears the session entirely; the next launch is a fresh sign-in with email and password.

Biometric does not replace your password. It only protects access to the app on this device; the password is still what authenticates you on the backend.

Server selector​

On the login screen, triple-tap the version label at the bottom of the screen to open a hidden developer panel. From there you can switch the app between production, staging, and a custom server URL. This is intended for developers and beta testers who need to test against a non-production backend without rebuilding the app.

For end users, the server is always production unless someone has explicitly switched it.

Push notifications​

Both native apps register a push token with the platform on first sign-in. The token is stored on the backend, scoped to the user and device.

However, the platform does not yet have the send-side pipeline wired to deliver pushes via APNs (iOS) or FCM (Android). Tokens are registered but no notification is actually delivered to the device. The notification bell inside the app works normally, and email notifications go out as configured. Treat OS-level pushes as not currently functional, and look for them in a future release.

File pickers and camera​

When you attach a file from native, the app opens the system file picker (iOS: Files app; Android: Documents). When you take a photo from inside an album, the app opens the system camera. Both routes work as expected; uploads continue in the background if you foreground a different app and come back.

The size and type limits are the same as the web. The most common one: photos cap at 20 MB and accept JPEG / PNG / GIF / WebP. iPhones that capture HEIC photos in "High Efficiency" mode currently see a confusing rejection — this is a known issue. The workaround is to switch the iPhone to "Most Compatible" (Settings → Camera → Formats) or to upload from a desktop.

Layout differences​

Native and mobile web share the same responsive layout — there is no separate mobile-only design. The rules:

  • Sidebars collapse to a drawer. The persistent web sidebar becomes a slide-out drawer triggered from a top-bar menu icon. The drawer auto-closes after navigation.
  • Multi-column dashboards become single-column. Bento grids reflow so each card is full-width. Stat cards stack; sparklines render inline.
  • Tables compress. Wide tables (member directories, dues invoices, audit logs) hide the lowest-priority columns on small screens and let you tap a row to see all fields. Sortable headers remain.
  • Dialogs become full-screen sheets. Edit dialogs, picker modals, and confirmation prompts render as bottom sheets that slide up from the bottom of the screen.
  • Dropdowns become native pickers. Select menus on iOS use the wheel picker; on Android they use the bottom-sheet selector. Long lists (e.g., member pickers, chapter pickers) render as searchable lists.
  • Forms reflow. Multi-column forms stack vertically. Date pickers use the OS-native date picker on native; mobile web falls back to the browser's date input.

These behaviors are automatic — no setting controls them.

Pull-to-refresh​

The dashboards (chapter, org, region) support pull-to-refresh: drag down from the top of the page and release to reload the data. This works on both web mobile and native, but the behavior on native is slightly different from a web pull-to-refresh.

The implementation uses manual touch listeners gated on the page being scrolled to the top and the swipe being unambiguously downward. This ensures that on native, the OS's own scroll behavior is preserved — you can scroll a long list without accidentally triggering a refresh, and pull-to-refresh only fires when you are at the top of the scrollable area. This refinement landed in v0.62.2 to fix a regression where the native dashboard was unscrollable after a v0.62.1 web fix.

Practically: drag from the very top of the dashboard, see the refresh indicator appear, release, and the page reloads.

Mobile-only quirks​

A few specific behaviors that are worth knowing about:

  • Background uploads. Attaching a large file and then switching apps lets the upload continue. When you return, the upload either completed or is still in progress with a visible indicator.
  • Network status. Capacitor's network status integration shows an "Offline" banner when the device loses connectivity. Most read views work from cache; writes queue and surface a "Will retry when online" message rather than failing.
  • Deep links. Sharing a link to a GreekManage page (e.g., a forum post URL) opens the page directly in the native app if installed. Falls back to the web app otherwise.
  • Keychain / shared password manager. iOS and Android both let you save your GreekManage password to the OS password manager. The next sign-in pre-fills from the OS, including biometric autofill on iOS.

How to join the mobile beta​

The iOS app is currently distributed via TestFlight. The Android app is on Google Play Internal Testing. Both are invite-only.

To request access, contact your platform admin and provide the email address you want associated with the invitation. The platform admin maintains the tester list and can add you. Once added, you receive an email from Apple (TestFlight) or Google (Play Internal Testing) with installation instructions.

Beta builds get pushed roughly weekly. The version number in the app shows which build you are on; pulling a fresh version via TestFlight or Play Internal updates the app.

For platform admins managing the mobile distribution, the workflow uses Fastlane lanes that ship from CI — see the engineering notes for details.

What is not yet on mobile​

A short list of things that work on web but not on native today:

  • OS-level push notifications (tokens register, but no APNs/FCM send pipeline yet)
  • HEIC photo upload (iOS default format is rejected; pending photo upload pipeline update)
  • Switch organization from the user menu (for users in multiple orgs, no in-app switcher exists today — sign out and back in)

These are tracked items rather than design choices and are expected to be filled in.

Last verified against v0.62.1 (2026-05-11). Native pull-to-refresh refined in v0.62.2.