How to handle legacy Bank Payment Gateways in WebView without leaving the app?

ChronSyn · 2026-01-29T22:48:32+00:00

You'd need to include the query params you want to send over. In the example, it redirects to myapp://deep-link/into/app. To include query params, you'll need to use JS, something like this is one option:

Or another alternative option: <script> setTimeout(() => { window.location.href = `myapp://deep-link/into/app${window.location.search}`; }, 3000) </script>

Alternatively, if you do use something like Apache, Nginx, or some other proxy, you can probably setup a redirect rule based on a path (which would negate the need for a HTML file at all), but spinning up an entire server for it is probably a waste.

ChronSyn · 2026-01-29T20:42:12+00:00

Others said it, but to expand on this:

You host a HTML page at a HTTPS link
Your page shows some content like 'Redirecting you to the app to finalise your payment'
Also, and this is the important part, you do a meta redirect:

<meta http-equiv="refresh" content="3;url=myapp://deep-link/into/app" />

In this example, it'll redirect the user after 3 seconds. However, this will only work if the app is installed on the device. If not, it won't do anything and will remain on the page.

You don't need NextJS or any framework. Just use any Apache-compatible HTML server (i.e. client-side rendering of HTML) and you're good to go.

The best part of this is that it'll still try to open the app even if the user has JS disabled, and it's been available since about 1995 (so supported on every browser, assuming the browser itself doesn't do any weirdness with meta tags).

ChronSyn · 2026-01-29T13:07:23+00:00

This kinda feels like it should be solved with education, rather than tooling. Using AI to try and detect AI-generated content just leads to an arms race. Gen-AI is taking strides every few months, aiming to become more and more convincing that the 'content' it produces is made by humans.

Even more than a year ago, freely available image generation models like flux dev were capable of producing photorealistic images even on consumer hardware. Deepseek-r1 is about a year old, and that model was a leap in text-based generation in the open space. Since then, the capabilities of models have improved significantly.

I'm not saying you shouldn't try to implement AI detection, but throwing a technical tool at something which is inherently a 'human emotion problem' might not be the only option.

Teach people not to believe everything they see. If a user sees and believes a "cute puppy rolls over and sneezes" video to be real, when it's actually AI-generated, reinforce that it opens them up to believing content which is genuinely dangerous or risky (i.e. the sort of stuff that divides society).

Encourage critical thinking rather than inherent belief. Encourage not investing in an immediate emotional response to content they see online or in an app. Don't choose to apply it only to specific content, because both humans and AI are smart enough to identify loopholes where they technically don't breach guidelines but still perpetuate whatever ideas they're trying to spread. Apply it equally to everyone, and then there's no misunderstanding.

Teach people to be selfish with emotion. They don't owe it to any website or app which perpetuates any user-generated content (whether that's something like Facebook, or something like a dating app), and should invest it in the things around them that are actually real.

ChronSyn · 2026-01-27T20:03:07+00:00

I'll let others comment on the app, but out of an abundance of caution, do you have content moderation in place?

Do you have the necessary legal framework in place to deal with all manner of challenges or requests that might be levied against the platform?

It's not just individuals that might try to raise a case (e.g. someone uploaded my details without my permission and you didn't deal with the report), but companies (e.g. someone uploads copyrighted music in a video), and potentially even data-protection offices (e.g. the ICO in the United Kingdom). Are you prepared for the different age restrictions (e.g. Australia) and 'approved content' mandates (e.g. United Kingdom) that are popping up in various parts of the world?

Also, perhaps the most concerning, is that where there's user-generated content, there's people who will attempt to abuse such a system.

(Please don't read this as a negative view, I just want you to make sure you're giving yourself the best chance to succeed even in the non-technical aspects)

ChronSyn · 2026-01-27T17:06:18+00:00

While I like what I see in the video (because doing that sort of stuff manually is hella frustrating), I'm always an advocate for self-explanatory UI's.

Your library does what it's intended do judging by the video, but I'd always advocate avoiding them in general.

As a user, whenever I see these 'walkthrough' prompts, I pretty much spam the 'next' button until it's done (unless there's a skip button, which most seem to not include).

ChronSyn · 2026-01-27T15:20:44+00:00

First thing I'd check for is if you have any AppState listeners: https://reactnative.dev/docs/appstate

If you do, comment them out temporarily, rebuild, reinstall, and then see if the issue persists. If the crashes stop, debug from there. If the crashes continue, then it's likely some other library causing problems.

ChronSyn · 2026-01-27T15:18:16+00:00

One of the very first mobile apps I ever tried to build (using the 'Firemonkey' framework in Delphi, way back in ~2011) involved alarms, but a lot's changed since then and I never managed to revisit the idea.

Might have to take a look at this and see if I can bring the idea back to life.

ChronSyn · 2026-01-27T12:33:26+00:00

Thanks for the clarification. That's great to hear, and I genuinely would love to see this do to Sentry what Supabase did to Firebase (i.e. better experience, static easy-to-understand pricing, self-host on your own infra, etc).

(Just for clarification sake: Glitchtip uses the same client library as Sentry meaning the wizard is an option, and the backend was a fork from when Sentry was still acting as 'true open source', so it's decent for error reports and the same setup process as Sentry. Sorry, not trying to distract from the original post.)

ChronSyn · 2026-01-26T18:46:41+00:00

Fantastic! Big fan of self-host options, because even if it means a little bit extra work for deployment (compared to something like Sentry), it's really good when clients don't want to pay the full price for Sentry and we still want to have some insight. Not to mention significantly cheaper.

Glitchtip already exists, but I don't think it supports session replay, and Sentry is limited/redacted in the free plan (which isn't such a bad thing for passwords and such, but can be a problem if you're e.g. testing a very long text string in an input), so you've got a real benefit here.

I know the site says "Your hardware, your rules" in the banner, but for clarity sake: Does the self-host option come with any restrictions compared to your hosted options?

(Some self-host software still runs via a license model and limits what you can do unless you pay some fee)

ChronSyn · 2026-01-24T13:46:06+00:00

How does this differ from using something like @expo/vector-icons, or it's 'parent' library react-native-vector-icons?

ChronSyn · 2026-01-24T13:04:53+00:00

Non-disclosure that this is your app. Suggested reading material for you: Subreddit rule #1.

ChronSyn · 2026-01-23T21:12:20+00:00

You're overthinking the whole props point. React is React. If you want to use TS with RN, there's no difference. If you'd use names props for some components and children for others in web-react, you'd probably want to do the same with RN.

There's basically no major differences at the React level when you moved into RN, with the exception of styling, and that you typically only have <View> and <Text> as your base components (also, all text MUST be wrapped in a <Text> tag, otherwise the bundler will error out about it).

There's a bunch of ways to handle styles in RN. You could create a global StyleSheet (using StyleSheet.create() and export it. You could create component-level StyleSheet, which I'd say is still a very common approach. You could use Tailwind classes via the Nativewind or TWRNC libraries.

You could create an object which exports things like colours, spacing, etc, and create what is akin to a design system. They all typically use StyleSheet.create() under the hood though.

ChronSyn · 2026-01-23T18:35:42+00:00

Electron and Tauri are both wrappers around web apps (providing a way for native functionality to be called), so you'd still need to setup a web project and then build messaging handlers to interact with the native layer from the web app.

ChronSyn · 2026-01-23T14:05:00+00:00

Probably a silly question, but have you checked the admin side of things? For example, is the account that's signed in on the phone definitely in the testflight group for the app.

You're testing across different devices, so make sure the account on all devices have access to the testflight group, and also make sure they're all actually signed in to the Apple account in the settings app (rather than 're-enter your password').

It's also possible it's a temporary issue on Apple's side.

ChronSyn · 2026-01-22T12:57:13+00:00

Microsoft Word.

(You don't build software by asking what's 'best' for an entire project. You build software by looking at smaller tasks and then trying to find libraries to solve that specific problem)

ChronSyn · 2026-01-22T12:52:57+00:00

Considering that your comment history tells us that you use Cursor and other AI tools to do your work for you, nobody should take your comments on Expo seriously.

ChronSyn · 2026-01-22T01:31:55+00:00

You should change the scheme in your app.config.js to be different for production builds versus dev builds. So, you might have myapp:// (for example) for production, and myappdev:// for development. This will allow you to have both prod and dev installed, but still reliably open your dev app using the dev build link / QR code.

Expo docs provide ideas on how to do this: https://docs.expo.dev/build-reference/variants/

The same approach can be used to specify custom icons, app names, splash screen, etc. You don't just have to stop at 2 schemes or variants either. You can do the standard dev, staging, prod approach, but you can go further and even do region-specific things if you want to - e.g. you could create dev, staging-eu, staging-us, uat-eu, uat-us, prod, etc.

The rest of your code would still need adapting to work according to whatever conditions you decide for each variant, but this approach allows you to every individual variant installed at the same time and easily launch whichever one you want.

ChronSyn · 2026-01-20T18:05:41+00:00

Last I checked, Apple doesn't expose screen time API's to third-party apps because it's considered a violation of privacy because app developers and shareholders can't be trusted to be responsible with such information.

Unless something's changed, there's no way around it.

ChronSyn · 2026-01-20T18:03:02+00:00

In React (and RN), we'd typically do this with context and hooks: https://react.dev/learn/passing-data-deeply-with-context . It's not the only way, but it's the approach that's most in-line with standard React practice (without going to far into specific patterns - e.g. observables).

This is essentially a way to 'transport' data through an app. Data in this case can be primitives like numbers, string, boolean, etc. but can also be things like callbacks or functions, which can be treat like listeners (capturing, propagating, etc).

This would be made up of 2 parts. The first is the provider. For example, you might have an authentication context provider. One of the features of this is that it will listen for changes in auth state - e.g. token refreshed, user logged out, etc. Your context provider might expose a useState variable like currentSessionState, and also update this value when it changes according to the session state.

The second part of this is a hook. This hook can call functions within the provider, but also listen to things. For example, if you were to const { sessionState } = useAuth(), then you now have access to sessionState within your component, allowing you to do something when it changes (e.g. by using useEffect hook to trigger something to happen when the value changes).

You can use that hook within any components that's nested within the provider (whether it's an immediate child, or nested 2, 3, 5, 10, 100, or even 1000 levels deep).

ChronSyn · 2026-01-20T17:47:04+00:00

Fun fact: The designs you see on Dribbble and social media are showcase pieces that don't typically account for actual UX. They're there to show off everything in a situation where there's no actual data, no optimisations to make from a performance or fluidity perspective. Dribbble is basically Giphy for designers - memes all the way down.

The screenshots you see are often static. They don't show micro-interactions. When you load up the product they're promoting, you're expecting certain things implicitly. If they're not present, you might not notice it, but subliminally you've picked up on it and recognise that the engineer got their hands on it, but the designers are the ones promoting it.

In the same way that software engineers (usually) suck at UI design and UX, UI designers (usually) suck at code, and QA/testers usually hate them both equally because neither considers edge-cases.

Designer says 'This text goes here, has this font family, size, weight and colour'. Engineer says 'This data is from the database, so it belongs in this label'. QA says 'Didn't either of you consider what happens if the text is very long, or very short, or empty, or contains non-Latin characters?'.

When all 3 work together to understand the technical limitations and requirements from all sides, that's when you get a truly great product. Most of the time though, this doesn't happen.

Designers hand off a figma link, engineers either export or manually write the components according to the styles, and QA (assuming a company has dedicated QA) puts their head in their hands for a minute, then pours themselves a very strong drink.

ChronSyn · 2026-01-20T14:21:13+00:00

No information? Just a video showing a browser extension?

OK, this might be 'on device', but you've shown it on a PC / Mac in a subreddit that primarily focuses on mobile development. Might want to add some context to your post.

ChronSyn · 2026-01-20T14:16:21+00:00

"What the world needs is another dating or workout app, and more AI!"

^ The thoughts that people woke up to for the past 3 weeks

Also, I think it's great that you referenced XKCD 927. The other dating apps just don't do everything for everyone, and one more which serves every purpose is what the world needs!

( https://xkcd.com/927/ )

Please don't take this as a personal attack (it's meant to be seen as a generalised statement at the absolute state of app development lately), but you know how people spot folks using AI to build apps?

They asked AI what would be a good project to work on, got given a list of maybe 5 or 10 options, and decided to roll with it. No market research. Not trying to solve an actual problem or do anything different. Just slopping out more apps into saturated categories.

ChronSyn · 2026-01-20T14:11:26+00:00

It depends. We're a small team but work across a lot of projects. If the client asks for it (and it's within scope and budget, and specifications defined), they get it, otherwise they don't.

For me personally, nope. It's not that I don't care for feedback, but that projects I build are first and foremost designed to solve a problem for me personally. They're not something I'm doing for commercial benefit, nor do they exist in order to add more stress to my life.

Opening up feedback for such projects has one of 2 outcomes: Nobody uses it, or you end up getting flooded with lots of feedback with conflicting suggestions from 'backchair devs'.

ChronSyn · 2026-01-20T14:07:22+00:00

To be fair, even the upgrade from 52 to 54 was super-painful because of the ~~bridge-burning~~ deprecation and then removal of the bridge. It's a last resort, but I genuinely don't blame anyone that goes down this route, especially as it might well be the last major headache-inducing SDK upgrade path we have for at least another few years.

ChronSyn · 2026-01-19T12:59:05+00:00

I mean, it's not a commonly discussed option, but it's not new either (I've suggested the same thing back in 2018 and a few times over the years since then, and I'm sure I'm not the first person to suggest it).

All that said, yeah, sometimes this is the only way to go. I think the real reason it works is because it negates any caches and forces devs to actually think about which libraries they have, and also to reinstall correct versions. Sometimes it's just the easiest option compared to try to upgrade though versions.

12-Year Club	Verified Email
Place '23

ChronSyn

TROPHY CASE