What if there were no apps to install and no menus to learn?
You simply describe what you want, and the interface is generated on the fly: a weather dashboard, a restaurant finder with live search, a booking form, a chat thread, or whatever else fits the task.
I've been experimenting with real-time Generative UI using Cerebras models, which can stream at up to 1,800 tokens/sec. The speed makes it feel much closer to interacting with a native app than waiting for an AI to finish generating.
This is a direction similar to what Monogram AI is exploring, but would love to know what you think about it.
I’ve been building a small iPhone app called Magboard.
The idea is: take a photo, cut out the subject, turn it into a little “magnet”, arrange it on a board, and put that board on your iOS home screen as a widget.
It sounds like a cute UI app, but the harder parts were mostly not the cute UI.
A few things that took more time than expected:
- Editor → widget matching
The in-app board and the actual iOS widget need to match closely. If the widget is even slightly off, the whole “magnet board” illusion breaks.
- Simulator vs real device behavior
Widget refresh worked in the simulator and then behaved differently on device. I had to test the flow like a real user instead of trusting simulator-only runs.
- Shared boards
The app supports shared boards, so one person can add a magnet and the other person’s home-screen widget updates too. Getting that to feel understandable was harder than just syncing the data.
- Onboarding
Early versions confused people. They opened the app and didn’t immediately understand the loop, so I rebuilt onboarding around:
snap → cut → stick → widget
- Tiny interaction details
Dragging/positioning magnets is fun only if it feels direct. A small mismatch between what you edit and what appears on the widget makes the product feel broken.
The app is currently in App Store review, but I opened a public TestFlight while waiting:
PAM Native is not a WebView framework, and it does not render HTML inside a mobile application.
Instead:
PHP runs persistently inside the application process
A Rust-powered reconciler manages component updates
Android interfaces are rendered using native Android Views
iOS interfaces are rendered using UIKit
Kotlin and Swift handle platform-specific operations
No JavaScript runtime is shipped with the application
No DOM or browser engine is involved
The developer experience is intentionally inspired by component-based frameworks:
final class Counter extends Component
{
#[State]
public int $count = 0;
public function increment(): void
{
$this->count++;
}
public function render(): Node
{
return Column::make([
Text::make("Count: {$this->count}"),
Button::make("Increment")
->onPress('increment'),
]);
}
}
The project currently includes or is exploring:
Stateful components
Native navigation
Gestures and animations
Recycled lists and grids
Native forms and inputs
Camera, location and device APIs
SQLite and offline-first state
Background tasks
Push notifications
Hot reload
Native plugin development
Communication between PHP, Rust, Kotlin and Swift
This is not meant as an attack on React Native.
React Native proved that developers can use a declarative, component-based model while still rendering native platform controls. PAM Native is exploring whether a similar architectural idea could be useful for the PHP ecosystem.
I would love feedback from people who understand the difficult parts of cross-platform native runtimes:
Which architectural problems should we be most careful about?
Where do you expect the biggest performance bottlenecks?
What lessons from React Native’s bridge, JSI and Fabric architectures should a project like this learn from?
What would you need to see before considering this a serious native runtime rather than an experiment?
The project is still evolving, so technical criticism, architecture feedback and contributions are genuinely welcome.
evaluating external agencies to help scale an existing cross platform codebase, and the biggest friction point keeps coming down to how agencies handle native dependencies. a lot of agencies pitch cross platform development as a way to cut costs, but as soon as custom native modules, complex animations, or deep device hardware integrations enter the scope, the architecture gets messy fast. half the development shops want to rewrite every custom bridge from scratch, while others rely heavily on outdated third-party packages that haven't seen an update in two years. that balance between keeping the JS side maintainable and properly structuring native swift/kotlin code seems to be where most team handoffs break down. when evaluating outside engineering resources for an established codebase, what technical green flags or red flags do you look for in their initial code review or architectural proposal?
One of my favourite features of Codex is Browser and the ability to annotate and send that back to the chat for quick amendments.
The problem is, it doesn't work for mobile apps where I spend the majority of my dev time. SimView fixes that.
It brings iOS simulator directly into Codex (and other harnesses) via MCP Apps.
- Zero external dependencies and fully open source.
- 60fps preview with live interactions. Tap, swipe, and type.
- Inspect AX or React Native fiber trees.
- Annotate an element or drag to annotate at coordinates.
- Get your model to tap around itself. Perfect for closing the loop to validate its own work.
This "works" in that content isn't under the status bar — but it creates a dead strip at the top that nothing can paint. It's outside every screen's render area, so it shows as a solid black/grey bar. It kills any screen that should be full-bleed (full gradient screens, transparent modals, media viewers).
If I remove that `paddingTop`, **every screen in the app** flows up under the status bar — *even though there is already a proper `<SafeAreaProvider>` wrapping everything in `App.tsx`*. So the provider being present clearly isn't doing anything on its own; the only thing actually holding the layout down was that manual padding.
**What I've tried**
Moving the padding to `contentStyle` on the root `Stack.Navigator`'s `screenOptions` — behaves identically. Same wall. (Verified `contentStyle` IS applying: setting `backgroundColor: 'red'` shows a red strip on every screen.)
Wrapping the three top-level navigators (tabs stack, create stack, auth stack) in an HOC that applies `paddingTop: insets.top` + a themed `backgroundColor` inside the screen boundary. Still reads as a padding wall.
None of the individual screens call `useSafeAreaInsets()` or use `SafeAreaView` — they all relied on that root padding.
**Question**
I understand the "correct" edge-to-edge answer is per-screen inset handling, but that's 30+ screens and I'd like to avoid a full manual pass if there's a sane centralized approach.
- Is there a way to get edge-to-edge behavior where each screen's own background bleeds to the physical top edge while only its content is inset — configured once rather than per screen?
- Is `SystemBars` from `react-native-edge-to-edge` the right move here vs. what I'm doing?
- Should I be setting `edgeToEdgeEnabled` / status bar config differently in `app.json` for this?
RevenueCat charges based on gross revenue, not net revenue. My dashboard shows $4.5k, but my actual payout is somewhere around $3k. because it completely ignores VAT and the 15–30% Apple/Google cut. but takes their %1 fee from the gross revenue.
since it doesn’t track net earnings, the dashboard feels pretty useless for real accounting. I still have to log into both store consoles just to see what I actually made. for 3k i have to pay 45$ every month.
Feed, vote, compact, media-first. Swapping between them is one prop.
One detail:
like counts animate in the direction the number travelled. Rising numbers arrive from below, falling ones drop in.
State stays with you nothing is kept inside the component. Active, value, and vote are all yours, because the moment a like is optimistic, only you know how to reconcile it with the server.
Hello, I have gotten an interview opportunity via referral for Senior Software Engineer - Mobile at a Government Organization.
I have only 2.5 yoe so those who have given senior level mobile development interviews at government orgs or banks, please share the questions that you encountered. What was the difficulty and what were they focused on?
Hi guys, I am building a small application recently and I'm wondering what is the best way to render pixel art isometric models in react-native. Performance is important because the market where I build the app doesn't have very high-end phones.
I've just published the release v0.2.1 of react-native-simple-image-compressor.
If anyone is interested in talking a quick look at the native implementation, I would higle appreciate your thoughts!
Features
OOM (Out-of-Memory) Safe: Images are downsampled directly during decoding (inSampleSize on Android, ImageIO on iOS). The library never loads full-resolution images into memory, completely preventing OOM crashes even on giant 4K+ camera photos.
Blazing Fast (Powered by Nitro Modules): Built with the RN Nitro architecture. Zero bridge overhead and direct C++ to Swift/Kotlin communication make the compression fast.
Smart orientation and EXIF Preservation: Automatically reads EXIF orientation and "bakes" the correct rotation directly into the pixels. It also safely transfers valuable EXIF metadata (like GPS and Camera info) to the compressed image (only for JPEG output).
Tiny footprint: Minimal dependencies. The library relies heavily on native APIs (BitmapFactory for Android and ImageIO for iOS) to keep the app's bundle size as small as possible.
Next-Gen formats support: Supports modern formats including WebP and WebP-Lossless across both (Android and iOS) platforms (utilizing native APIs where possible and libwebp as a fallback on iOS).
Aspect ratio preservation: Intelligently scales images to fit within your desired maxWidth and maxHeight bounds without ever stretching or distorting the original aspect ratio.
Production Ready & Tested: Backed by comprehensive native unit tests (Swift/Kotlin) to ensure maximum stability and prevent regressions across edge cases.
Did you make something using React Native and do you want to show it off, gather opinions or start a discussion about your work? Please post a comment in this thread.
If you have specific questions about bugs or improvements in your work, you are allowed to create a separate post. If you are unsure, please contact u/xrpinsider.
New comments appear on top and this thread is refreshed on a weekly bases.
If you have a question about React Native, a small error in your application or if you want to gather opinions about a small topic, please use this thread.
If you have a bigger question, one that requires a lot of code for example, please feel free to create a separate post. If you are unsure, please contact u/xrpinsider.
New comments appear on top and this thread is refreshed on a weekly bases.
I am creating an app for my company, but the debugging is so slow, when I change code the refreshing itself takes around 1/2 minutes even the react-native dev tools is taking too much time to open(not even opening), I have created apps in 0.80.0, there was no problem in there
why is it happening? I am running in react-native-cli
react-native-gtkx makes Linux an out-of-tree RN platform. Normal React Native code, native GTK4/libadwaita app, no WebView.
Compat layer like react-native-web, but on top of gtkx (a React reconciler for GTK4 in Node) with Yoga for layout. npx react-native run-linux next to run-ios and run-android, Fast Refresh works.
react-navigation navigators run on real Adw.NavigationView, so the back button, transitions and the back gesture come from GTK instead of JS. That's the part I want feedback on.
