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}
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?
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.
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".
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! :)
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.
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 ;)
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 ;)
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.
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'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.
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?
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 :)
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?
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.
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 :)
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.
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" :/
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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 ;).
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.
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.
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.
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?
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?
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.
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!
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".
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.
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.
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.
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.
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).
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.
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'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.
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) :)
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.
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.
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.
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'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.
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 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.
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.
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!
183 comments
[ 2.9 ms ] story [ 239 ms ] threadI 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.
I can definitely see an use for 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 :)
1: https://itunes.apple.com/ca/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 :)
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.
[1] https://play.google.com/store/apps/details?id=com.bashtian.a...
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/
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.
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 did: https://jasonette.github.io/documentation/actions/
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.
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') }}
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.
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.
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.
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.
Even if it's as simple as "just build and submit".
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) :)
Position right is something we don't see often. This shows it is a great way to make your page easier to read.
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.
Well, there seem to be great number of uses for this. I think this is excellent idea. Off to make an app... or two.
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!