Show HN: Make an app by adding JSON to this app
github.com
github.com
Like when you have an ever expanding product line and new categories are being added all the time. Ever wondered why Amazon uses web views all over ?
Many E-commerce companies would love to be able to do extensive A/B testing or add analytics on the fly but are crippled by the App store and the limitations of native apps. Some have even built versions of this themselves.
What we need is an Android port of this and then this will be some hot shit. I am willing to help on the iOS side in any way I can.
It sounds stupid but I work in E-commerce and have wished for this many times.
It's an XML/HTML-like syntax for building native Apple TV apps using native components, but loaded over HTTP and without having to write Objc/Swift code. It's very much like this (or React Native), but in XML.
I hate the walled gardens of the iOS/Android world and the fact that multi platform frameworks are so difficult. Seeing things like this are encouraging.
Isn't this (kind of) what Android Instant Apps (will) do(es)? link: https://developer.android.com/topic/instant-apps/index.html
I have built similar tools as well. You can't be generic because that requires programming skills. Focus on high value niches
And make everything look very very good. And perform very very fast.
I think it's really cool, and I hope you guys like it. I would appreciate any kind of feedback!
I quite like the look from the limited glance over. (Probably going in my list for the next tiny thing I have to build).
Also there's an undocumented mode called "offline", where the JSON loads from the server once and after that it always loads from the initially fetched JSON stored locally. You just need to set "head": {"offline": "true}
Hope this answers the question!
If you wanted to version apps, I think you could version it at git level, or just think of it as an API deployment. No?
Still, very cool!
Or one could fork the code and change a couple of lines to make this work, technically it would be just a couple of lines of code, but I think policy-wise it needs to be thought out.
Please follow the project and feel free to start an issue thread, we can discuss further! :)
With this you could hide some porn apps in appStore so I don't know how "legal" it is, but that's just a minor problem ;)
However I'm no iOS developer, so could you give me a cursory explanation on how it works? I mean, I can imagine creating a framework that has "empty" screens, and then just loading data into them, but this seems like it can do much more.
So for example, if I want an app with say 4 screens, and GPS access (if supported) and a few buttons, do you have all those objects already in memory and just copy them and inject the data to show on screen?
Or maybe it's too early and I'm missing something. Very neat though!
> it instantiates .. components on demand
In general, to wrap your information engine around how information engines wrap around components, check out this marvelous design pattern: https://en.wikipedia.org/wiki/Visitor_pattern , like here https://github.com/Jasonette/JASONETTE-iOS/blob/develop/app/...
I've read about the Visitor pattern before, but did not link it to an engine like this.
edit: just in case, i am just criticizing the support of Apple's monopoly.
Congrats on shipping. This thing is cool.
Of course with that extreme of a view, web views would break the rules too. :-P
In any case, it's a cool project. I hope to see more production stuff using it.
Out of curiosity, what prompted you to start building this?
I extracted Jasonette out from that app so others can use it too :)
Question: I see that XCode is required, I don't have a Mac only an iPhone). Any possible way to use Jasonette without a Mac? I've seen some services like Mac in a cloud but I was more thinking about alternative methods. For example, as the only setup required is to provide the URL, couldn't you create a generic Jasonette test/dev app where you can provide the url and do the testing/development directly only on the json side?
I thought my idea of having a test Jasonette app where you put the url from the app after the boot to do your testing could be very easily doable and way not it could allow also to test the various existing apps that OP created: he could create a test app that downloads a list of his demo apps (so it is always up to date), show a dropdown or similar to choose the demo app + allow you to specify your own custom test url using the keyboard of the device. In this way you have both a demo and a test application :)
In practice, it's very easy to do.
This is how many UX Prototyping apps, like Invision or Origami works. You download the Origami Studio iPhone app, input in the URL of your prototype, and it loads it into it.
This is an excellent solution for getting up and running with Jasonette without a Mac.
In fact, I first created Jason about 5 months ago, and have since been working on open sourcing it, which became Jasonette.
One warning though, note that this current version of Jason is not completely up to date with the most recent version of Jasonette (I've been too busy trying to release the open source), which means about 95% of the apps should work but not all. I plan to push an update soon, please follow the project or join the slack channel to stay updated :)
Note that this current version of Jason is not completely up to date with the most recent version of Jasonette, so some apps may not work. I plan to push an update soon, please follow the project or join the slack channel to stay updated :)
This is going to help a lot of people that want to prototype or even deploy a full featured app without spending months of coding.
And then you could add scripting...
For a simple app, I think this is a good idea - going to play around with it for some simple apps.
In the end, HTML is just a standard for defining view element hierarchies; CSS is just a standard for specifying declarative layout constraints on those element hierarchies; and JavaScript is (supposed to be) just a standard for specifying how interactions with those views are bound to your view-controller. (The view-controller in a browser originally being an NPAPI <object> like a Java or ActiveX applet.)
None of these standard formats has any particular tie to the way web browsers use them. The standards, of course, go beyond syntax, and also specify the HTML elements, CSS properties, and JS DOM that define "the web" as a platform. But it's perfectly possible to use HTML, CSS, and JS syntax—with standard parsers!—to power your own windowing toolkit.
Define your windowing toolkit's view hierarchy format as "HTML syntax, but with these valid elements" (where they map to the controls in the toolkit.) Define your windowing toolkit's layout constraint properties format as "CSS but with these valid properties", where these map to the properties the toolkit exposes on the controls. And finally, drop-in a JS engine, but don't tell it to expose any APIs to the view to control things from Javascript; rather just mirror the API of the view-controller attached to the view as a set of opaque callback functions that can be hooked up to the elements of the view with addEventListener.
XUL or XAML could have just been this. ePub is basically just this (though in some implementations a webview is used.)
And, as a side-benefit, it becomes very easy to, like ePub, define your element and layout-constraint formats as supersets of HTML and CSS, such that people can still use familiar HTML elements and CSS properties for inline rich-text styling inside <label>s et al, while still using your toolkit's controls for everything else.
And then you have the problem that most clients will break with the new HTML structure.
In contrast, a separately designed JSON or XML structure (if you follow some simply sanity rules) can be kept backwards compatible for a long time.
And I'm trying to build something that's optimized for the future devices, and when you're building something from scratch you have freedom to make a choice, and I think JSON makes a lot of sense going forward, since this is just the beginning of this project.
Hope this makes sense!
And all computers and devices made in the last century have no problem dealing with XML, HTML, JS over the wire - in fact this is exactly what web browsers have been doing. So even though you're dealing with native iOS apps and not webpages, that doesn't mean you can't use a similar XML format(or any other document markup language) along with a proper scripting language. And if you insist on staying close to JSON, you could go an all JS approach and use JS(instead of JSON) to describe your views, and also be able to embed JS computations - this is exactly what React does, and does very well.
And again, JSON is not a document markup language, so optimizing it for displaying documents/interfaces seems futile when you can just use XML and save yourself and the interpreter some pain.
That's not simple. JSON is simple. Yours is two things, JSON is one thing. And a lot of people are responding positively to this, so the author may be on to something. JSON is NOT the best language for full expressiveness, you're absolutely right about that. But it's simple, it's one single syntax (not two), and it feels like "just configuration" even though you're doing the same amount of logic.
> so optimizing it for displaying documents/interfaces seems futile
I mean, this guy did it, didn't he? And it's open source so now you can too.
I'm glad people build new things. This is cool. Maybe it'll catch on, maybe it won't, but I'm glad he used JSON and not XML+JS. We already have phonegap and cocoon for that ;).
It's ugly as hell and always has been. I suspect only Java developers could love such a tedious, verbose thing ;-)
Plus, JSON is really close to YAML/coffeescript/Ruby/python/pug so I can write even less keystrokes and compile to JSON. I'd be really interested to see your interface implemented without the braces and brackets. I bet that would make it extremely approachable to non-programmers.
I've thought of making a Native renderer for some subset of HTML like Google AMP that would work on both Android and iOS. That way all existing web frameworks could generate native apps.
But you'd have to do something like this to ensure that you're not breaking Apples rule of not making your own browser engine.
https://news.ycombinator.com/submitted?id=gliechtenstein
It’s easy to forget that good ideas take a lot of time and iterations until they become magical. Great things do not happen overnight and without much sacrifice. The majority of people would give up the first time the community dismissed their prototype.
Big props for not giving up.
For what it's worth most med-high profile games are built on similar techniques albeit at a larger scale. You're largely building tools and reusable components that let designers, artists and animators define behavior, look & feel.
It goes by a couple different names but the most common one I see is "Content Driven Development". As you've noticed it has all sorts of benefits like fast iteration time, updates on the fly and ability to allow non-coders to bring in their perspectives to build experiences.
Don't let the ivory tower haters get you down, it's a very powerful and valid approach in the appropriate domains.
But It can easy lead to inner platform effect. Not needed complexity. And in JSON you can't write JS code (needed for e.g. event handlers).
So I switched to JS. Still data-driven approach (simple hierarchical objects with data), but with power of JS (and if you're use Babel, you could use JSX for your DSL).
So: I don't think JSON is best format for what you try to achieve. It's just so limited.
Besides what is added value of Jasonette? When I look on Jasonette I have feeling that it's just reinvents ReactJS but in JSON not JSX. Not sure if there is much profit with JSON format alone.
I think data-driven approach is huge win for that. It's all data after all.
What is the problem? Creating visual editor is hard. Idea is obvious, but implementation, ux etc. is hard (I see sometimes visual editors for apps and most of it are sh*t).
Please follow the project if you're interested in finding out where this goes :)
https://en.wikipedia.org/wiki/Inner-platform_effect
I, too, went down the path of JSON -> Compiler -> Code, and I essentially just made a worse version of what I was looking to simplify.
My goal was to make something that will help myself build, iterate, extend my existing app much faster, and it really did, so that's when I realized it would be great if I can open this up so others can use it as well.
To be more specific, nowadays I can build, iterate, and extend apps significantly faster, as in what used to take couple of days I can now build in 30 minutes. Maybe it's just me but I'm sure if I can do it, anyone can do it.
What is the most advanced application you have created with this? What functionality do you think is still lacking?
If you were to try to create a full featured app I imagine you'd find that working in Swift is the better option.
What this reveals to me is that the App Store submission and update process is so time consuming you would rather write your logic in Json than in native Swift/ObjC.
If Xcode let you instantaneously push app binary updates would this be as useful?
I think a good exercise would be to find a popular mobile app and recreate all of the functionality with Jasonette, developing missing features where you need them. A demo showing you recreate Tinder or iMessage by bolting a few pieces of logic together in Jasonette would go a long way in maturing the functionality and demonstrating its viability.
Have you considered weaving Parse or Firebase into this?
If you create a tool that just converts IB views to JSON you can demonstrate progress much faster and learn and experiment with what the requirements of the final editor are. It will be much easier to stand up and way less effort than maintaining your own editor codebase while the project is young. Your time is the most valuable thing you have so don't spend it creating a new editor which could be its own project in itself. You want to put it towards expanding missing functionality between JSON and native components. One day when you find success and if you really still need to limit the user you can move all the functions you made for converting Interface Builder views into your own custom editor.
I think first thing I would do is take a very complicated interface view from a native project and analyze the view hierarchy and report errors to the user like "Warning: Nested UITableViews are not supported in Jasonette", "UIButton delegate will be ignored", etc. Then once you create this sort of 'unit test' that the IB is well-formatted you can then go about exporting it to JSON.
There may be a world where you actually are able to use all of the functionality of IB and don't ever have to have your own editor.
So I wouldn't be surprised if they react to that differently.
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, Mac OS X, or tvOS apps.
Older policy:
3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
Apple once prohibited a Commodore 64 emulator because it had a BASIC intepreter. But they've lightened up a bit.
It's definitely allowed for JS.
This looks like code to me, even if it is wrapped in JSON:
> {{#each posts}}
> {{# if ('type' in this) && (type=='stories') }}
But as for HTML, I decided to incorporate it natively because it's def worth it: https://jasonette.github.io/documentation/templates/#html
http://blog.crudzilla.com/2016/10/managing-configurations-wi...
If you want to try the demo, send me an email (in my profile) and I will give you the login.
If you had enough JSON-to-native "modules", basically anyone could write a native app in a few hours (since functionality in most apps is pretty much standard stuff)!
Hell, if you pushed this further you could create an app store for code, letting you buy additional modules to plug into your app like lego.
[1] https://play.google.com/store/apps/details?id=com.bashtian.a...
Why not also support the web? With an Immutable store you could easily use react to display this app on the web without needing native install.
Great job. Look forward to seeing where this goes.
I usually don't start with CSS let alone SCSS for websites, basic HTML shows them instant results for what they typed and gives them more endurance for the longer learning curve (but more power) provided by CSS.
Interesting is having declarative templates on the client side, instead of server-side, for accessing json APIs. Of course you can do this in browsers (and it is done), but this is cleaner and simpler, being a fresh reinvention.
Haven't checked yet, but is there a spec for the json?
Position right is something we don't see often. This shows it is a great way to make your page easier to read.
* How is this different from any of the other declarative app building systems that have, as yet, failed to take the world at large by storm?
* Why JSON? I get it's universal but it's also annoying to write. Why didn't you consider YAML or , even better, HOCON?
* Do you really think loop syntax in a declarative language is a good idea, because to me it always comes across as a nasty anti-pattern to get around the fact that declarative languages don't tend to handle this well?
Otherwise, nice effort. Better than anything I've ever shown to the world :-)
From my experience, a JSON representation works very well for a big percentage of all the apps out there, and you can often do without custom code. Good job creating this open-source version, it looks very expressive and useful!
The format itself is designed for a particular problem domain, namely outputting mobile-application specific controls and behaviours.
It would be an interesting exercise to extract those aspects into a custom vocab for JSON-LD + Hydra (or Siren, or (insert) other generic hypermedia formats).
http://www.markus-lanthaler.com/hydra/
It would also be interesting to have the hypermedia format defined as a schema somewhere.
[0]: web version can be found at - https://www.99.co/singapore/rent
However, the comparison ends there. This is great! Its just too simple to make an app and probably when the app grows one could create a transpiler to generate this json
[edit] I really like how you're participating in the comments and how you reply. I really hope you do well, you seem like a nice person :-)
I built these in around 15 minutes each, and you can too, once you get used to the markup you can too (which also is great since all you need to learn is the consistent JSON syntax which works for actions, view layouts, and styling. There is no real "environment setup" and "becoming a programmer" process that most people need to go through just to get anything running).
Well, there seem to be great number of uses for this. I think this is excellent idea. Off to make an app... or two.
Failed to create provisioning profile. The app ID "home.master.Instagram-UI-example.Jasonette.com.githubusercontent.raw" cannot be registered to your development team. Change your bundle identifier to a unique string to try again.
Anyone knows whats up? I ran the setup and inputted 2 and supplied the URL from the Github..
Im in the process of making my own static site, and im storing as much of configuration and content as possible in json.
Now if only it were possible to place a generic version of this app on the App Store and allow users to load in the JSON for whatever app they want. Sadly I very much doubt Apple would allow it.
You don't really need to use those templates at all. What those templates do is let you do advanced stuff like client-side rendering, dynamic data processing, etc.
But you can build a full fledged app WITHOUT any of those advanced stuff. Watch the video on the website and you'll get it immediately!
It was acquired by PushIO which was acquired by Oracle. Along the way the SDK stopped getting updates with new iOS versions and Apps stopped working.
The yearly updates of the iOS SDK will impose a bunch of work on SDKs like this to keep up. A good model for open source.
All the best to the author, might be a good model for a consulting gig around the open source SDK for sure.
The way this works is like how a web browser works, all the code you will ever need is already in the binary, the JSON markup is just used to custom-construct your own app to your liking in realtime.
Long answer: it depends on what you're using it for. You're allowed to use things like this, or React Native or Cordova/Phonegap and deliver updates OTA (without going through the App Store review process) as long as you don't "significantly change the app from what we see during the review process".
Of course, how to interpret this is up to you, and is always a danger on the App Store. But support of this model is promoted by Apple themselves by TVMLKit, an API for building native Apple TV apps via JS+XML, delivered OTA over HTTP.
Great project, by the way!
this actually reminded me of a startup which lets you create a native app using API documentation ( swagger ).
Edit : If I can find the bookmark, I will the link to that startup here.
Yeah, you can only get so far being declarative. Miracles don't happen.
What's the performance like? Does it handle switching views back and forth? Keep state?
It does handle switching back and forth and everything else you would expect from a native app, because it is native (and not an emulation) :)
This is the next iteration of Titanium Appcelerator and Xamarin style apps (which basically do the same thing but internally).
Even if it's as simple as "just build and submit".