Show HN: Make an app by adding JSON to this app(github.com)
github.com
Show HN: Make an app by adding JSON to this app
https://github.com/Jasonette/JASONETTE-iOS?hn
183 comments
I've built similar platforms.
Naturally, I think they are awesome.
They are a core part of very valuable products like SAP, Salesforce, etc.
You will get a lot of push back from high developers who prefer direct access to the native api or html.
Please don't let them discourage you.
My response to them is that they can build reusable components that are driven by your json layer (win-win).
There are enough developers who will benefit.
Try to get funding sooner than later.
I waited too long.
You can't keep up building this by yourself.
Thank you for the advice! Honestly it means a lot!
Don't listen to the haters. This is extremely valuable. Especially in E-commerce.
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.
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.
> What we need is an Android port of this and then this will be some hot shit.
Isn't this (kind of) what Android Instant Apps (will) do(es)? link: https://developer.android.com/topic/instant-apps/index.html
Isn't this (kind of) what Android Instant Apps (will) do(es)? link: https://developer.android.com/topic/instant-apps/index.html
When I read the Readme, I was thinking this could get a lot of limitations of store app updates. (As long as this thing can use a cached version of your json if it can't connect to the Interwebs).
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.
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.
Thank you! Please follow the project and join the Slack channel if you can :)
But my personal view is that we should support a syntax that is a subset or derivative of HTML while being performant so that any existing web framework can generate smooth native apps (while also side stepping Apples rules against implementing a browser engine :P).
It sounds stupid but I work in E-commerce and have wished for this many times.
It sounds stupid but I work in E-commerce and have wished for this many times.
That sounds like React Native: https://facebook.github.io/react-native/
Have you seen Apple's TVML?
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.
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 think the key win here is very highly stylized native components that very elegant which solve specific use cases (content selection, database browsing, shops, etc). That way you can compete with react and friends who try to be everything to everybody.
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 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.
Yes, keep it up! I shipped a fragment of something similar in an iOS app a few years ago, allowing my client to customize a complex form component of the app dynamically. It proved very useful.
Guys, the author here. This is my first open source project and I worked really hard on it for 5 months.
I think it's really cool, and I hope you guys like it. I would appreciate any kind of feedback!
I think it's really cool, and I hope you guys like it. I would appreciate any kind of feedback!
This is very interesting.
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!
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!
Almost correct. To be precise, it doesn't have the objects in memory, it instantiates all the native components on demand based on the JSON recipe. And all of them of course go away once you close that view.
>> how it works
> 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/...
> 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/...
Aha! thanks to both of you for the answer.
I've read about the Visitor pattern before, but did not link it to an engine like this.
I've read about the Visitor pattern before, but did not link it to an engine like this.
this is weird man, I had a similar idea like about a year ago, and just started coding some prototypes of it this week, my original idea was to scan a QR code and then you'll be presented with a native app, and I needed a way to code the elements of the app, and i didn't want to waste time writing a parser, so I used Json too lol. I was coding for android, maybe we should join forces ;)
Hi Ethan,
it looks very interesting, one feedback and one question:
Feedback: you should try to slow down the gif demos, at least in my Chrome/laptop they are quite fast and the viewer can't really appreciate it completely
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?
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?
You can run the latest MacOS in VMware on Windows. It works perfectly - Google "VMware Unlocker" as a starting point. This setup actually runs faster than the older Mac Mini I bought specifically to develop for iOS, and it's obviously much more convenient to be able to use a Mac from Windows whenever needed. Both Xcode and a $99 Apple Developer subscription are required if you wish to distribute the app anyway, so I'd suggest you go the VMware route if you don't want to buy Mac hardware or use a cloud service.
Yes, it's called Jason, it's on the appstore https://itunes.apple.com/us/app/jason./id1095557868?mt=8
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 :)
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 :)
I tried to download it (the description doesn't really match what we were discussing but still.. I tried) and then I tried instagram, weather and the maps from jasonpedia and they all fail with "please enter a valid url" :/
I heard that running MacOS on a non-Apple hardware was not considered a legal solution. Am I wrong?
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 :)
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 :)
IANAL but I'm fairly certain that given Apple's resources, if they wanted to stop this practice, they'd have obliterated VMWare Unlocker from the map. It's been around for years, they certainly know about it, and they haven't done anything about it. So if not expressly legal, they certainly don't seem to have a problem with it.
> I thought my idea of having a test Jasonette app where you put the url from the app after the boot
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.
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.
Technically/'legally' it's against the EULA - it only supports virtualising macOS on Apple hardware.
In practice, it's very easy to do.
In practice, it's very easy to do.
Answer: Please try Jason on the appstore https://itunes.apple.com/us/app/jason./id1095557868?mt=8
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 :)
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 :)
He actually has released a version like that [1], I believe this is what he's referring to when he says he extracted Jasonette from an existing app.
1: https://itunes.apple.com/ca/app/jason./id1095557868?mt=8
1: https://itunes.apple.com/ca/app/jason./id1095557868?mt=8
I think it's really cool too. I especially love open-source projects like this that just work. I also appreciate your significant effort to make extensive and helpful documentation.
Out of curiosity, what prompted you to start building this?
Out of curiosity, what prompted you to start building this?
I didn't start from a grandeur goal, but had an existing app on the appstore and was frustrated with every single aspect of the app development process. So I started implementing little by little just to make it easier, and ended up with an app that's actually a precursor to Jasonette.
I extracted Jasonette out from that app so others can use it too :)
I extracted Jasonette out from that app so others can use it too :)
What's the local fallback like? Does this continue to work at all if the client does something like change networks?
I quite like the look from the limited glance over. (Probably going in my list for the next tiny thing I have to build).
I quite like the look from the limited glance over. (Probably going in my list for the next tiny thing I have to build).
There's a $cache action where you can store any JSON object into cache associated with the current url and reuse it later https://jasonette.github.io/documentation/actions/#cache-vs-...
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!
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!
It'd be even better if you could ship a version to the App Store with an embedded JSON. That way you'll always have some version of your app. Or does it do that already?
Why would you want to have a version of your app? I think one of the coolest part is it works like a website but natively.
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?
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?
I didn't ask the question, but had the same thought. Basically, what if the first time someone loads your app, they don't have a network connection? After the first load, it sounds like I can handle the issue with the cache, but I care a lot about a good experience the first time someone opens the app.
Still, very cool!
Still, very cool!
Currently, it is possible to set a data-uri as the root url (in a correct format https://en.wikipedia.org/wiki/Data_URI_scheme) I think that's one way you could handle this situation.
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! :)
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! :)
This indeed: there are more cases than you think where someone downloads your app but has no internet connection when using it. And that could be the first time. Shipping a JSON file ensures the end user will always have something. That something could be as simple as a message "I'm loading data, internet connection is required".
Versioning means you can use Continuous Deployment easier. Once all the tests pass for your new feature, it gets shipped, but not before.
Yup that's what I meant by API versioning. Instead of having to deploy the physical app to the appstore, you are deploying your API, since basically you're building your native app on the server.
Just came here to say this is AWSOME, keep up the good work and i wish you the best.
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.
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.
Does this break any of Apple's rules?
nope!
I've heard Android pulling apps that try to update themselves outside of the store. I was thinking this would be a great way to get by the update process in general, since you could cache the json if off-line or pull a new version if you're online.
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.
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.
Can you explain how it doesn't? I immediately think of embedding an interpreter in this thing for real, general application development.
Congrats on shipping. This thing is cool.
Congrats on shipping. This thing is cool.
Thank you! I think this thread is relevant: https://news.ycombinator.com/item?id=12879487
Really cool, I always thought about something like this, but yours is more powerful that I have ever thought XD. The thing about this Is you can make IDEs and UI designers "easily" because you already have the engine. So good job ;)
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 ;)
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 ;)
This is fantastic. Thank you for taking the time to create it. This looks like an amazingly simple way to create a prototype.
Thank you! Why stop at prototype though? All you need is a couple of more lines to actually make it work (make network requests, call native functions, react to user interaction etc) :)
I worked in mobile development for a while and had this idea in the back of my head during that time. I am glad to see that you have implemented it! Most frameworks walk the ugly line of having one foot in a standard stack (like a web stack) and one foot in the native-mobile world.
Congratulations on your first OSS project! It definitely seems I could use this.
This is awesome! Thanks for doing the work to make the project accessible to everyone!
Your project is really cool, you should be proud :) !
I don't haz Apple but it looks great.
Great, but too bad, it's for getting into the jail.
edit: just in case, i am just criticizing the support of Apple's monopoly.
edit: just in case, i am just criticizing the support of Apple's monopoly.
What monopoly? There are many times more android devices than iOS devices.
Instead of JSON, you could also consider sending XML markup. Oh wait, or maybe reuse an existing SGML/XML standard called...HTML.
And then you could add scripting...
And then you could add scripting...
The problem with this is that there will always be some sort of disadvantage HTML5/hybrid/etc apps have over real native apps. Things like interaction, calendar integration, 3D graphics, etc, etc never work as well as they do as for native apps. In addition, if they do work on a technical level, Apple or Google may add an API tomorrow that either breaks, or you'll have to wait on the supplier of your HTML5 magic framework to add support, etc. If you want high quality, responsive UIs and apps, native is the way to go.
For a simple app, I think this is a good idea - going to play around with it for some simple apps.
For a simple app, I think this is a good idea - going to play around with it for some simple apps.
You're assuming that choosing HTML as a format forces you to use all the associated web-platform goop to render it.
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.
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.
Have you seen Apple's TVML? It's exactly what you're describing https://developer.apple.com/library/content/documentation/La...
The problem here is backwards compatiblity. As your HTML file evolves, you will want to restructure it. CSS only takes you that far, at some point you need to adjust your HTML structure.
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 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.
I totally understand where you're coming from. Here's my rationale: Most mobile devices and future devices will already use JSON as main method of data transmission.
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 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!
This doesn't make sense. JSON is used because it's a handy data interchange format, but it doesn't mean it's the best tool for every job.
XML is a document markup language that is much, much better than JSON for describing interfaces and alike. And even then it's not really ideal for describing control flow and computations that are needed for any meaningful app that is not a static page (see XAML, AngularJS, FXML, - they do have some power but they're still tied to real programming languages: C#, Javascript, and Java, respectively.)
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.
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.
> use a similar XML format(or any other document markup language) along with a proper scripting language
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 ;).
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 ;).
While you make some sense, you lost me the second you started talking about XML.
It's ugly as hell and always has been. I suspect only Java developers could love such a tedious, verbose thing ;-)
It's ugly as hell and always has been. I suspect only Java developers could love such a tedious, verbose thing ;-)
Everything that everyone ever told me had to be implemented in an XML flavor, I have implemented in JSON without trouble. This includes iOS and Android views and manifests, HTML (I choose jade/pug/haml), JSX (pug/hyperscript), AJAX (always gets parsed into native JS object). It's never been a problem for my career, and if enforced with strict formatting and whitespace, causes less errors due to closing tag, encoding, or nesting issues.
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.
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.
> you could add scripting
I did: https://jasonette.github.io/documentation/actions/
I did: https://jasonette.github.io/documentation/actions/
Hey everyone ,
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.
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.
Easy- transpile it ahead of time. The ban is on runtimes.
Yes, at surface it looks like re-inventing the web/html, but to use HTML for defining app you would need to add all the native elements as HTML tags to the vocabulary and that would be a lot. HTML was made to make hypertext with things which were imagined in early 90s, NAML (native app markup language) 25 yrs later should support all the bells and whistles we expect from native app UX 25 years later. I would say attempts to reuse/extend HTML for native app UX definition (Titanium, React Native etc) are more terrible hacks than creating new clean room markup language as here is done.
Yeah because HTML apps always turn out so well...
I found it interesting that the author has actually submitted the same idea 4 times to varying degrees of interest:
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.
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.
Exactly my thought. You need a bit of luck along with good project to get viral on HN. Otherday I saw simple PDF memo generator got lots of traction while so many other cool apps didn't even surface up.
Very cool.
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.
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.
Thank you for the encouraging words!! { ˃̵̑ᴥ˂̵̑}b
Taking this a step further, perhaps this can become a quick mock up tool ?
Been there, done that. When I coded games, I made some simple JSON based file format and almost whole game was in form of JSON. I even implemented conditional and loops in JSON.
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.
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.
Please consider reading this.
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.
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.
Thanks for the article. I am sorry to hear what happened to your project, but I think, in my case because I didn't build this from scratch, but it was extracted out from an existing app, I was able to get this to a point where I'm very satisfied with the result.
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.
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.
yeah, predefined actions for often used features is good (if you assure that it would be possible to add some custom JS action if needed), but frankly I think this project could be better (I mean, really better, it would be killer app), if you would go further and made visual editor for that. Some sort of modern WYSIWYG. Nobody wants to edit manually plain JSON files... But if editor could let you to make apps without code and generate/modify these JSONs for you, it would be nice.
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).
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).
Thanks for the feedback! We discuss that issue here: https://github.com/Jasonette/JASONETTE-iOS/issues/4
Please follow the project if you're interested in finding out where this goes :)
Please follow the project if you're interested in finding out where this goes :)
Really great stuff!
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?
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?
How is Apple going to react when you change the JSON (and thus the app, as seen by the user) without getting approval for the changes?
If you are showing a web page inside your app and the web page contents changed, is that a problem too? I mean where's the line defined by apple for the term "change".
Apple only allows the iOS WebKit framework, so in a way, all apps that show webpages are simply wrappers around an Apple browser.
So I wouldn't be surprised if they react to that differently.
So I wouldn't be surprised if they react to that differently.
Will Apple eject this app from their web store for downloading code? Maybe not. Current Apple policy:
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.
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.
https://microsoft.github.io/code-push/
It's definitely allowed for JS.
It's definitely allowed for JS.
> nor may they download, install, or execute code
This looks like code to me, even if it is wrapped in JSON:
> {{#each posts}}
> {{# if ('type' in this) && (type=='stories') }}
This looks like code to me, even if it is wrapped in JSON:
> {{#each posts}}
> {{# if ('type' in this) && (type=='stories') }}
There's an issue thread where we're discussing this: https://github.com/Jasonette/JASONETTE-iOS/issues/4
The advantages of creating your own wysiwyg editor is that you can control exactly what functionality Jasonette supports and allow developers to create views across different platforms (right now Xcode is Mac only). But have you considered starting with Interface Builder and creating a tool to convert IB views to JSON? Interface Builder is home to a lot of developers who already understand how to use that tool, asking devs to work in a new half baked editor would probably be frustrating and add more complexity/moving parts which is your enemy as a new project/endeavor.
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.
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.
Interesting, I haven't thought of that idea. I'll make a note so when we get to it we'll make sure to look into the option. Thank you so much for the advice!
My fear is that for most apps Jasonette will be too abstract and require lower level languages like Swift/ObjC to be more expressive.
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?
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?
Yup, try this https://jasonbase.com/things/zn1/edit
This is very interesting, although JSON is not a very comfortable format to build manually - I think writing in YAML or CSON would be much cleaner to read/write, and easily converted to JSON.
Also, any plans on building a UI for generating this JSON? If you have predefined components, you could make some sort of designer that builds the JSON for the user, that could turn into a commercial project I think.
I have the perfect solution for this type of JSON configuration management, I wrote up a post on it:
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.
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.
Transpilers should be pretty straight forward. Maybe even for HTML syntax.
Yeah we were actually discussing whether we should support HJSON natively or not https://github.com/Jasonette/JASONETTE-iOS/issues/5
But as for HTML, I decided to incorporate it natively because it's def worth it: https://jasonette.github.io/documentation/templates/#html
But as for HTML, I decided to incorporate it natively because it's def worth it: https://jasonette.github.io/documentation/templates/#html
Wow this is really impressive.
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.
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.
Wow that is actually a brilliant idea. Would you ever consider making an android version?
I had a similar idea and started with an android app [1] for creating an app template with a simple interface directly on the device. It's not as powerful as this, but maybe I can implement basic support for these templates. But right now this would be only like a viewer and not something that can be used for own apps, not sure how useful that could be.
[1] https://play.google.com/store/apps/details?id=com.bashtian.a...
[1] https://play.google.com/store/apps/details?id=com.bashtian.a...
There is something called json2view[0] for android which allows you to render the views according the specific json format. Definitely not as powerful as Jasonette but could be useful sometimes.
Very neat and well put together! Thank you for taking the time to prepare nice documentation to go along with it! Congrats on your release!
Thank you! I had no idea documentation would be this hard. As a wise man said, I learned that open source project is "1% inspiration and 99% documentation" :)
I need some kind of service to create a wrapper app (yes, I know, everyone hates it and so do I) for website, only add a bit branding and hamburger menu. I've been looking for free or paid solutions, but I haven't found any.
Congratulations! I think you have "discovered" QML, my favorite environment for rapid GUI development, incredibly intuitive. You may want to to look into that for inspiration.
This is really cool.
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.
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.
What would be the feasability of an Android port? I like the concept, but hate that it's for a platform that I refuse to touch with a ten-foot pole.
Students (especially younger ones) often need more help seeing the light at the end of the learning tunnel. Something like this is a great start to teaching development and spurring them onto an actual language.
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.
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.
OK, this obviously looks like a web browser (native...) using json instead of (xml-like) html, though it's not good as a markup language.
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.
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.
Is anyone working on an Android port? I'd definitely want to give it a go.
Haven't checked yet, but is there a spec for the json?
Haven't checked yet, but is there a spec for the json?
Small detail I enjoyed from your website (on mobile, might be different for desktop) : header text positioned to the right of the screen (or content div).
Position right is something we don't see often. This shows it is a great way to make your page easier to read.
Position right is something we don't see often. This shows it is a great way to make your page easier to read.
Thank you for noticing! :)
I'm at a restaurant reading this so I haven't had a chance to test it out yet but having reviewed the website I already see a massive use for this: Programmatic app building. This is an awesome idea. I can't wait to play with it.
This plus Huginn will be awesome for dynamic apps
Looks like a new name from jasonclient.org. Previously discussed 6 months ago: https://news.ycombinator.com/item?id=11736817
Yup I worked on open sourcing it for 6 months! This is the open source version of Jasonclient
Nice to see you getting so much positive feedback, here is some negative feedback balance it out:
* 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 :-)
* 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 :-)
This seems similar to what is used internally at AppSpotr[1] (disclaimer: I'm a former employee). They also use JSON to represent apps that can be rendered in iOS/Android clients. The difference is that apps must be built using a WYSIWYG editor rather than by editing the JSON directly.
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!
[1] https://www.appspotr.com/
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!
[1] https://www.appspotr.com/
So what this is, is an IOS hypermedia (AKA true REST) client, for consuming APIs serving a custom (as opposed to generic) hypermedia format.
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.
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.
This is really great one. Shameless plug, we've built similar (but smaller) concept for the filter form of our apps[0] (cross platform, natively for Web, Android and iOS) mainly because we were tired of having to change the search filter form fields and logics in every app update. Now, we just have to change the configuration and the filter form changes instantly.
[0]: web version can be found at - https://www.99.co/singapore/rent
[0]: web version can be found at - https://www.99.co/singapore/rent
This is awesome! I actually had this same idea and built a platform for non-technical people to have the ability to build native apps. We picked Xamarin.Forms as our mobile framework because that way we could target most of the mobile platforms and share as much code between those project. We also picked Drupal a CMS to give non-techies an easy framework to build things out. I am going to keep an eye on this project for some different ideas and maybe one day we can pick your brain with our idea/platform.
This looks very cool. And tempting at the first glance. As I read more of the documentation, I can't help stop comparing it with React-native for the rendering part. I remember somebody mentioning server-rendered mobile apps in one of the early react-native apps. This is pretty much achieving that.
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
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
Thanks! You'd be pleasantly surprised to learn what's coming up, please follow the project to stay in touch :)
Android and web dev here, how would you compare this to nativescript and such? Instead of learning a new dsl, isn't web to native simpler? Unless you're developing a game I've never found native to be necessary. I'm one of those devs who moved from native to hybrid for faster development speed
[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 :-)
[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 :-)
Thank you! If you thought these JS based app development was fast, you're in for a real treat! Check out these apps I wrote as exercise: https://github.com/gliechtenstein/botlist.json & https://github.com/gliechtenstein/kitty.json
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).
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).
One use case: you have a game or app, and want to publish rich promo screens for new features or in game events. Even to old versions of clients.
We once built a tiny in-house framework for this, based on Lua (game downloaded a package of Lua script and image resources and displayed the promo). If there was something ready to use (and multiplatform - at least android and ios), we could have saved quite some development time.
I know, it is too simple, people's head just exploded.
Well, there seem to be great number of uses for this. I think this is excellent idea. Off to make an app... or two.
Well, there seem to be great number of uses for this. I think this is excellent idea. Off to make an app... or two.
I tried building the instagram clone but get:
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..
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..
The app ID is alreay in use. Change the string (add your name or something)
I made something very similar in 2004. Instead of JSON, you would supply PHP arrays. The enabled to mix in some conditional code and make it more flexible for different usage patterns. We shipped a pretty big ERP application this way. I have since left the company, but the software still works on 200+ installations.
How do app permissions work? Is there a way to make Jasonette request only the permissions needed by my JSON?
what kind of app permissions?
Push notifications/camera/photo access and such?
Late to the game--where does logic go? Looping? DB access? Would they be written in Objective C as actions?
OK, I missed that actions can be chained through an optional 'success' action: https://jasonette.github.io/documentation/actions/#b-handlin...
This is very cool! Do you have a spec to share? First thing i thought of is that it would be awesome to write webapp and static site generator implementations of the jason spec.
Im in the process of making my own static site, and im storing as much of configuration and content as possible in json.
Im in the process of making my own static site, and im storing as much of configuration and content as possible in json.
This is a wonderful idea! Making app development faster and easier can only be a good thing.
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.
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.
This is quite useful with a Huginn server setup to dynamically feed JSON out https://github.com/cantino/huginn
Neat project! I've been working on something similar here: https://github.com/mcudich/TemplateKit
Native app newbie here. Can this solution be used to present data tables?
[deleted]
Well you do need to be a little bit of a programmer. You have loops in there, and evaluating properties of objects, etc. Interesting idea and it looks like you've done a nice job of it.
I think I need to make some changes to the main screenshots, those are actually one of the most advanced features of Jasonette.
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!
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!
Hey Buddy!, Great concept and smooth execution. Something for Android?
Cool idea. But I'm wondering if this is allowed in the App Store?
Yes it is. There was an SDK called TapLynx back in the day made by Brent Simmons of NewsGator and Innesential [0] fame. . It was $600 and a quick way to get an App released in the late App gold rush days with only an XML file.
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.
[0] http://inessential.com/
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.
[0] http://inessential.com/
Yup, in fact this was extracted from production apps on the appstore. Here's one: www.textethan.com
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.
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.
What do you mean by extracted? Did those applications use something similar or did you collaborate with the creators?
No that's me. I'm Ethan, and I created that Ethan app. Jasonette was born out of my frustration with various aspects of working on the Ethan app. So that app (and all other apps I have created since) currently run on Jasonette. Sorry for the confusion with names.
Short answer, yes.
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.
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.
This doesn't download any binary code so I think it's fine
This is nice. I always wondered why something like this isn't available. I built a nested tab-bar menu system for an e-commerce app recently which can be generated from a json file.
What about Push Notifications? Are they supported somehow?
Great project, by the way!
Great project, by the way!
Is is possible to include some kind rich text/html editor that can send data back to a server via JSON? Is it possible to send any user data back to a server with Jasonette?
Congrats on the release !
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.
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.
This is awesome. Do you plan on releasing an Android version?
> "text": "{{$jason.find('#about h2').text().trim()}}"
Yeah, you can only get so far being declarative. Miracles don't happen.
Yeah, you can only get so far being declarative. Miracles don't happen.
The more I scrolled down this page the more impressed I got.
What's the performance like? Does it handle switching views back and forth? Keep state?
What's the performance like? Does it handle switching views back and forth? Keep state?
Thanks! I think the best way to see is to actually jump in and try it out. I tried my best to make the onboarding as seamless as possible, so normally it should take like 20 seconds from download to having the app on your phone (assuming you already have latest XCode installed)
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) :)
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) :)
Great Job.
This is the next iteration of Titanium Appcelerator and Xamarin style apps (which basically do the same thing but internally).
This is the next iteration of Titanium Appcelerator and Xamarin style apps (which basically do the same thing but internally).
I would recommend adding documentation for shipping to the App Store.
Even if it's as simple as "just build and submit".
Even if it's as simple as "just build and submit".
Never thought you could do that much with just JSON, this looks very promising for students or for fast prototyping.
Is there support for loading more pieces of the app on demand (so the server can generate them?)
can you elaborate?
This looks really interesting. How can you localise an app's UI when using this?
I immediately thought of backing this with a simple node.js server and using templating for this.
Looks cool but what kind of apps are you supposed to build with this?
This is great. I am new to iOS and this seems very promising.
FWIW, the name is quite similar to https://github.com/google/jsonnet
how to make an app in 15 min | How to develop a mobile app free
https://www.youtube.com/watch?v=tnsYachOafk
Didn't know Red Hat spams hacker news for some crappy mobile app thing!