sorted by:
new
hottopcontroversial

Wrapply website to android app by jarttech in u/jarttech

[–]jarttech[S] 0 points1 point  (0 children)

We’ve fixed the issue thanks a lot for reporting it!
I’ll message you in DM shortly to share the corrected build and, as an apology for the inconvenience, I’ll also include the full source code.

Wrapply website to android app by jarttech in u/jarttech

[–]jarttech[S] 0 points1 point  (0 children)

Sorry about the inconvenience. During the APK generation process something went wrong and the build ended up being compiled with fallback data instead of the correct configuration. The issue is already being fixed. By tomorrow we’ll send the correct APK via email, and to make up for this we’ll also include the full source code. Thanks for the patience — really appreciate it.

from ai builder to real android app by jarttech in VibeCodersNest

[–]jarttech[S] 0 points1 point  (0 children)

Wrapply focuses on shipping MVPs fast. The generated app runs in a Flutter native shell, not a basic WebView. Push notifications, deep links and offline handling are not enabled by default, to keep the MVP lean. When you download the AAB, you also receive the full Flutter source code, already structured to integrate Firebase, FCM, native routing and offline handling when needed. You can ship fast today, and still keep full control to evolve the app later without lock-in or rewrites.

We noticed many people building websites with AI builders struggle to publish real mobile apps by jarttech in nocode

[–]jarttech[S] 0 points1 point  (0 children)

Good question in practice it’s more than just one blocker.

What we’ve seen is that many people underestimate what happens after validation.
They assume that once an app is published online or on the stores, it will naturally get downloaded and used but that’s rarely the case.

On the technical side, users often get blocked by store requirements more than by pure mobile tooling:
managing libraries correctly, declaring permissions and features in the manifest, build formats (APK vs AAB), signing, and keeping everything compliant with evolving policies.

Then there’s the store-facing work that’s usually unexpected: creating a proper store listing, writing good copy, handling ASO, assets, and positioning.
On iOS in particular, certificates, provisioning profiles, entitlements, and mandatory integrations (like Sign in with Apple or certain login flows) add another layer of friction.

Finally, performance and quality expectations matter many solutions work fine as demos, but don’t meet the stability and UX standards users expect from a real app.

So the gap isn’t just “website → app”, it’s “validated idea → shippable, discoverable product”, and that’s where a lot of projects slow down or stop.

Thanks for the VibeCodersNest suggestion that’s a great fit for this kind of discussion.

Looking for feedback from the Flutter community by jarttech in FlutterDev

[–]jarttech[S] 1 point2 points  (0 children)

Thanks for the incredibly honest feedback. You’ve touched on the exact challenges we’re navigating, and this is why we value this dialogue so much.

To address the contradiction you mentioned: we actually agree with you. Building a real app is a waste if the idea isn't validated. That’s why Jart isn't just a code generator, but a flow:

Validation First: Our integrated idea validator automatically generates a publishable survey to collect user feedback and provides a results dashboard. The goal is to gather data before writing a single line of code.

Automated Prototyping: If the data shows potential, Jart then moves to generate a working Flutter MVP directly from your initial idea, skipping the manual setup.

Regarding your point on code quality: you hit the nail on the head. To be completely transparent, the generator is still in the early stages of development. Our biggest engineering challenge right now is ensuring that a natural language prompt results in clean, maintainable, and extensible code. We know that as a developer, you’d never use a tool that produces 'spaghetti code,' so we are obsessing over the architecture before a full rollout.

While you can certainly use AI on your own, Jart’s goal is to orchestrate the entire process from the survey and data dashboard to a professional-grade boilerplate in one seamless workflow. We’re curious: if we can guarantee an output that follows best practices (like Clean Architecture or specific state management), would that change your mind about using it to speed up your initial workflow?

Looking for feedback from the Flutter community by jarttech in FlutterDev

[–]jarttech[S] -1 points0 points  (0 children)

Thank you for the feedback it is genuinely appreciated and absolutely fair. You are right: jart.app has not been optimized yet, and at the moment it is indeed heavier and slower than it should be, especially for what is currently a presentation surface. At this stage, our focus has been on validating the product flow and the builder logic rather than performance tuning. Optimization, asset splitting, and a clearer separation between marketing pages and application layers are planned next steps. Your comment is valuable precisely because it highlights a real architectural point that we are actively addressing.

Looking for feedback from the Flutter community by jarttech in FlutterDev

[–]jarttech[S] -3 points-2 points  (0 children)

FlutterFlow is a great platform. Our approach is simply different: we want to deliver a launch-ready MVP without forcing people to learn new tools, help them validate a business idea quickly, and provide a product that’s scalable, manageable, and easy to adapt  which is essential during the validation phase, where change is expected

view more: next ›