Apple wants to make it easy for non-programmers to build iOS apps - Page 2

It seems to be over the inventors' heads that making software is more than just knowing how to code, you truly need to know something about computers and how they work in order to make good software. The same goes for the web, so many people who blog think they can build websites, it's just not that simple.

If you build the right way to do it , you can write some great apps. Multimedia fusion even has an IOS exporter already .Some of the games and apps you are using might have already been created with no programming.

One example of a game made this way for IOS is pocket ninjas.

I hear you. Apple do usually provide a lot of pre designed templates in their creation tools to at least make stuff that looks half way decent.

So this is saying that I could've gotten rich by building my own fart app?

Having the ability to build quick and simple front-ends to hosted server apps or data would be very useful to companies. This needs hooks to access data stored on servers or in iCloud, including data shared by groups of users, not just a individuals. iCloud could also act as a method to host/distribute these apps to groups.

The type of apps this would be useful for are simple data sharing and distribution apps, not heavy computation or customized user interfaces and games. A company might use it to push out information to users, such as a library of product information or other internal docs. User input would be minimal and simplified. The ability to "mashup" data from various hosted sources and present them to users would be key.

Now I see it as just another web development tool. That is if I understand this correctly in that the tool develops web pages.

However if they think the average business person could ever do anything constructive with this tool I have to wonder. If it works at all it will be with mid level technical people that don't have the time to do real apps yet have projects that don't justify a massive project and the corresponding costs.

There are more than a few people pressed for time that might be able to produce something useful. Maybe not the type of apps you would present to customers but apps none the less.

What this looks like to me is the reflection behind app storyboarding, as introduced with iOS 5 and Xcode 4.2. Programming is far from being eliminated, but more elements could well be automated as the concept evolves.

http://developer.apple.com/library/i...roduction.html

This is my thought, a tool for internal apps you want no one else to see. These sorts of tools are great but unfortunately are often under appreciated by the likes of Apple because they don't see successful apps out in the wild.

Honestly this makes me wonder if this is a DashCode replacement. The web focus makes me think this may be so. It might not be a bad idea if the libs give high level access to SQLlite data bases and other OS features. It would be especially nice if the app came with a high level bar code reading lib that works in conjunction with the on board camera. Given these two features I could see many quickly developed apps for internal usage.

Ok allow me to rephrase then: I think it's a bad idea Apple is wasting resources on this, not because I think they are unable to execute the idea better than everyone before them, but because I think the idea is fundamentally flawed in the first place. If all you need is a glorified storyboarding tool, you don't have to wait for Apple, we've had that for years. I remember ObjectVision from the Windows 3.1 era, it basically tried the exact same idea 20 years ago. Many others followed, but the idea still went nowhere. Google App Inventor is basically the same thing as ObjectVision, just a lot fancier.

The probem is that you cannot create complex things involving abstract logic, without investing the time to learn the tools that allow you to actually express those things. Anything that tries to relieve the 'programmer' from dealing what is basically the essence of programming -abstract logic- will inevitably end up as either too restricted to achieve anything useful, or too complex to fulfill its purpose. Somewhere in the middle of this road sits Flash: easy enough for the most basic prototyping for non-programmers, but far too complex if you want to mke anything half-way decent with it. The amount of crap made by people without a programming background, who got a little carried away by the deceptive easiness of the tool and started to explore the complex world of serious ActionScript development should serve well as an example of the problems with 'development tools for the masses'.


I'm not debating the exciting prospect of a tool that makes it so easy to create real applications, I'm just saying the idea is fundamentally flawed and self-contradictory. I can understand you would love to be able to create simple applications without having to program, just like I would love to be able to shoot and edit professional videos without having to learn anything about how to set up a scene, how to use a professional camera, or how to write an engaging story.

Just don't get your hopes up, that's all I'm saying. Unless you are aiming for ridiculously trivial stuff (which you could already do today), or generic 13-a-dozen crap, you will have to invest in learning how to write computer programs the hard way. There is no substitute.

Agree. We might see widgets in iOS 6. Or not. A tiny minority of iOS users wants them for some reason.

I'm trying to relate this to something current and my best guess is that this is a DashCode replacement. If beefed up significantly it could find use as a tool to build those utility apps that companies often find hard to justify the time and expense to do a proper app.

No you can't but there is more than iCons to this App. The problem I find with iOS devices though is that business solutions often require I/O to the real world. With iOS hardware there is a big brick wall between the device and the real world.

For example at work we still make use of a time app written BASIC years ago to configure printers. Not VisualBASIC mind you but the really old basic from back in the DOS days. The thing is it works and nobody has time to write a modern app for such a simple chore. This is the type of business appilcation (use) something like this might be useful for.

The problem is of course that I/O brick wall. Even though Apple is selling a lot of "I" devices to business I still don't think they get it. The simple realities of physical I/O as in USB, and file transfer make the machines far less useful than the could be. What Apple needs is a $20, 30 pin to RS232 adapter that doesn't require kissing ass to make use of the adapter. Though honestly I would rather have a standard USB port where I could plug in such adapters and memory sticks. With the memory sticks you would need the ability to read from that stick.

Why? Because I can walk up to a tool, such as a Plasma etcher, and pull data off it only via a USB stick. It would be very nice to have an app that could analyze that data in the field. As you can see this isn't something anybody is likely to dedicate time to and in fact is where one would often use tools like Numbers, Excel, or even MSAccess. As it is now trying to use something like an iPad for this is just to painful to even describe though it could be the ideal tool. The problem is even if this tool comes to the light of day, it won't be at all useful for these sorts of business needs no matter how well the software itself is done. The reason of course is that the hardware blocks you from this sort of thing.

Seems like a lot of snobbery from professional programmers going on in this thread. I think this patent is a great idea. I would love to build a basic app for a local community project I'm involved with but I just don't have the time or energy to learn programming. There is no reason why creating an iOS app shouldn't be just as easy as creating a good website is these days with all the great software out there. No reason at all.

I fail to see the educational value as it glosses over programming and web technologies. The biggest potential in my mind is for internal commercial "Apps" and for the distribution of catalogs and technical info to customers.

Or at least part of your web site. It effectively deals with the bandwidth and data usage charges. The bandwidth problem is quickly going away, but I doubt we will ever see an end to data caps. Thus it can be very advantageous for a company to be able to put catalogs and technical data on a customers "I" device. This doesn't even get into the not always having a data connection issue.

Frankly I got a couple of Apps on my iPad right now that are either catalogs or technical documentation. I believe these are native Apps though I'm not sure. The thing is in one case the App works far better than the web interface the company has.

It's not ridiculous at all.

So long as those of us that know code can still use it. And the code it produces isn't as bad as iWeb output. That was some ugly code. And bloated.

Right. So if I understand correctly you are basically saying the abominations people who know nothing about web technology create, serve as a good example why creating iOS applications should be as simple as dicking around in FrontPage pretending you know how to build a good website?

With statements like this you'll be sure to trigger the web developer snobs and the web designer snobs as well, just like the professional programmer snobs posting in this topic. They're all the same, thinking they took an education and years of experience to do stuff anyone could do with just a few better tools. I mean, we've only been trying to make software development easy for a measly 40 years or something

Now if you excuse me, I'm off to continue working on my DIY neurosurgery kit, it's about time anyone can do brain surgery. No reason it shouldn't be as easy as clicking together a website. No reason at all.

They mentioned JavaScript, not java. But I agree with ecs (except: don't allow java!) and strongly disagree with z3r0. Keep byte-code and interpreted languages off of iOS platforms. Java and other non-compiled-to-object-code languages are CPU-hogs and battery-killers. You may like how it looks when you're coding it, but your iPhone or iPad would choke and nearly die. This is the main reason why android devices will never have the battery-life or stability that iOS devices enjoy.

Why don't you say what you really mean

You are a REAL software programmer that had to learn how to write everything by hand and in your opinion that is THE only way to write anything. Anything created any other way is utter crap. How dare Appke turn their backs on the right of doing things by encouraging people to not learn how write code by hand like you had to.

I bet you had to walk 5 kilometers to school every day in the snow, with no shoes. And uphill both ways.

For example I see AlienBlue as a far better way to access Reddit than the web site. Somebody was kind enough to repackage Pythons documentation site as an app and that works really well. I actuall have at least one companies app that does a better job of presenting catalog info than their web site. Done right these sorts of apps can save you time and bandwidth/data accumulation.

Now there are many apps that repackage web sites in such a way that the App is worthless. Arstechnica comes to mind here. There have been others that make me wonder why bother but the point is people shouldn't damn the idea for a few bad apples.

As to your question what's the point, why do people download PDFs when they can go search the net for that document in the future? There are many reasons but not having to search for it is one, the need for a specific revision is another, the desire to annotate is common and there are many others. In some cases having a local copy of a sight can be just as useful as having a local copy of a PDF. I know of at least a couple of companies that have the only documentation for their products as a web site. On a Mac you might use wget or another tool to download that documentation. So a company offering up its web site as an app is really just offering an alternative.

You are bashing a tool as bad based on some people that haven't used it well. Yes that makes you a snob.

Next you will bash stoves because Some people can't cook well

[/QUOTE]

I'd estimate that I use the IMDb app at least a couple of times a week. It is another app I consider more useful than the web site. I actually consider it to be well done.

On the other hand I have to agree about the pop up wanting you to down load the sites app. It sucks royally. I see these all the time in various forums I visit, I've never even tried them out.

Almost every web page you visit has some JavaScript in it, which is what an interpreted language. The likes of Python or JavaScript are perfectly fine for utility apps and would have little impact on the battery. It is up to the programmer to choose the best language for his app, if you don't like the battery life of anyone app then don't buy it.

Frankly your position is assinine, it is extremely easy to code up an App in Objective C that wastes the battery too. Just because one language is easier to program in doesn't imply that it isn't worthwhile. One needs to judge how the app is used and by whom to determine the suitable suite of tools to use.

Disregarding the fact that over the years I've seen attempt after attempt fail at achieving anything more than glorified storyboarding, or the insight I got from doing software development on a daily basis, that 90% of the work involved with creating good software requires application of abstract logic that requires a language of expression that is orthogonal to visually arranging and connecting some prefab components, yes, you could say that I'm taking the time to express my thoughts about his topic here, for no other reason than showing off how awesome I am, getting paid a pretty sweet salary just to sit behind a computer doing stuff charlituna on AppleInsider would be able to do if he just had better tools.



Maybe you should take a step back and read what you are actually writing here, because logic like that is not actually supporting your argument. To take your analogy: I'm still waiting for a stove that will make me a head chef, so I don't have to invest time learning about ingredients, ways of preparation, which flavors go well together, and all those other pesky details that real chefs have to learn first.

But don't feel bad, logic is pretty hard, lots of people have problems with it. If only they had better tools...

Clickteam sells an iOS runtime for MMF apps already: http://www.clickteam.com/website/usa...velopment.html

EDIT: Oops... somehow overlooked your "flash and iOS games" comment...

We will see the day when people are able to engage computers at a much higher level than offered today. This project really doesn't seem to be there but one could hold out hope that it will eventually get there. Remember there was a time when the likes of Siri would have been thought impossible.

In any event I suspect this whole bit of news is way overblown as to me this sounds like a beefed up DashCode instead of a app development break through. Frankly I don't see DashCode as a bad thing either, it is a tool that has its place in this world just as C++ and SQL have their place. Your absolute dismissal of this app is perplexing to say the least. I suppose that the people using Keynote to prototype users interfaces is too far out for you also.

The thing here is that open minds should evaluate a tool based on what it can do for them, simplify for them or otherwise get to an end product quicker. Maybe this isn't the optimal solution but frankly if it helps even to slightly reduce development effort it would we well worthwhile to have. Just as something like Keynote can replace sketch pads ans sticky notes so can an app like this find a role.

Nope, not assinine [sic] in the least. We're talking batteries here. What makes you think that java or Python programmers would restrict themselves to "utility apps"? And yes, javascript is expensive, but the interpreter is maintained/optimized by Apple, so it runs well.

No one said these languages are not worthwhile, but their usage should be restricted to running on single-user machines that do not run on batteries. Sorry, but for most programmers the "best language for his app" is the one that's easiest for him, not necessarily the one that uses the battery most efficiently.

That 90% number is just plain garbage. There are many business apps that don't require complex logic or massive efforts at abstract logic. That many can't handle even simple programming is a fact. I have personal experience here picking up projects from engineers that couldn't program to save their jobs and self destructed with VisualBasic. Sadly this on an app that required little in the way of abstract thought.

No looking at iOS and the hipuge waste of time that goes into supporting basic UI elements I actually believe Apple could go a very long way to improving the position of the developer. We might actually get to the point where 90% of the effort goes to actual business logic. As it is now one spends far more time with UI development, antiquated approaches to user interface element handling and boiler plate code to drive the UI. Non of this pertains it self to business logic or abstract concepts.


You see I don't totally disagree with you because I've seen the results of people trying to program that don't have a clue. On the flip side I've seen cooks with nothing but a bit of charcoal and cast iron cook a fantastic meal. Likewise I've seen rather intelligent people produce some really nice software with just a little bit of knowledge and rudimentary tools.

Well let's be honest that statement won't get you anywhere. The whole industry has revolved around building better tools, tools used by professionals mind you. A good tool can go a long way to helping you understand your code professional or not.

OK, the only reason JavaScript makes the grade is because it is maintained by Apple? I'm having a hard time believing you really mean that, but let's say for arguement Apple offered up Ruby as an option, would that make it any better since Apple is supporting the code?

As to what the programmers restrict themselves to that is up to the development team building the app. Users are free to reject any app they might think is a problem.

Single user machines, oh come on do you have even the slightest clue where these languages are used. Python, Ruby and the like are often languages of choice on server handing very high volumes of traffic. I have no idea where you got the idea that they are only suitable for single user machines.

As to batteries, again you have failed to show how they are anymore of an energy issues that Objective C. Anybody can write bad code in JavaScript, all one has to do is look at some of the competitive forums out there that can bring my iPad to a crawl. Appleinsider doesn't have this issue which most likely indicates better JavaScript programming. This idea that energy usage is a function of the language belies the fact that the programmer himself can have a huge impact on batter life through his coding technique. Sure C compiled down to highly optimized object code has the potential to use less energy, but like I said it isn't even a significant issue relative to the other issues.

That is my whole point. Battery usage is as much a function of the programmer as it is the language. Even when delivering the same basic app with the same language, a web forum for example in JavaScript, the performance and battery impact can vary widely. This should be rather obvious to users of the various forums about the web.

Maybe it is, I simply haven't installed it. The thing is I am typically on a webpage when I want to look up an actor or title so I want to stay in Safari and just switch to a new page or use that same page to locate the info.

Actually, not true. I also use prototyping/visualization applications Axure and iRise. In Axure, one can create lo-fi or hi-fi interactive prototypes. It looks and behaves almost like the actual thing. It's only been around for several years and adding great functionality with every release.

iRise is the more robust of the two. It actually does create business logic, IN USABLE CODE, for the back-end (Java or .NET) with any mainstream DB. This is done by creating visual elements and assigning properties, relationships, and interactive behaviors to them. It's actually pretty amazing.

Both of them allow you to generate a specifications doc for designers and developers.

This is just the beginning. As we move closer to creating ontologies for everything we do, use, say, want, etc., we are getting that much closer to creating software that can "understand" what we want to to. This is AI in the making.

No worry for devs. They'll just shift from doing mundane tasks to building applications that...well, build apps, for every vertical, market, category, etc.

In my lifetime, I WILL be able to "tell" software such as this, to make an application that does...

Think about it

Actually no one has seen an app like this.

There are similar apps but from what I can gather there is no app that allows you to create one app for multiple platforms.

Where I see this as being truly amazing is if it allows you to create one app that runs on Macs and all iOS devices no matter what they are. Development time will be killed.

Sometimes you just want to create a quick and dirty app as an interface for something. For example I'm currently building an online helpdesk system using PHP and MySQL. However, I would also like to develop a proper app for iOS devices to be able to make updates quickly and easily to the database wherever they are. Having to learn two programming languages to do this makes it kind of difficult to do.

A system like this will make it so much easier to do.

If keynote was marketed as making it easier to streamline your logistics, sell more widgets, or helping you find a cure for cancer, just because you can make nice presentations about these topics, yes, I would dismiss it as I dismiss any tool that promises to bring software development to the masses, without requiring you to actually learn how to program stuff. Just like keynote does not help you to produce better content, a programming language or Application Inventor or whatever does not help you to solve the abstract problems involved in software development.


I agree with the basic premise, but let's not pretend stuff like mentioned in this article is anything new. It's old stuff and it has been for at least a decade, I've seen it all before. If you look at the evolution of conventional programming languages you'll see that the latest and greatest ones already reduced the amount of boilerplate code you have to write to a minimum, the SDK's and frameworks already solve almost any generic problem you'll encounter, the language constructs offered by the various modern languages already converged to a set that is more or less agreed on is useful, etc. Almost all advancements in programming languages you see today are about parallelism and how to make it easier to harness it without all the pitfalls, a topic the complexities of which are almost impossible to explain to someone without a pretty advanced background in programming and how computers work. Yet, with all the tools we have, writing good software is fundamentally still almost exactly as hard as 30 years ago. Less cumbersome, faster, and safer, but not much easier, at least not for anything besides GUI design. Trying to sugarcoat that fact by making your development environment more accessible by using more visual elements and activities has been tried before. It's too restrictive for almost anything non-trivial.


I may have overstated that a little but I still stand by my statement. Obviously not every piece of software consists of 90% business logic, but you still require application of abstract logic in some form or another for about any task related to writing it. Even if you are just hooking up a touch event to a button, having it increment some kind of counter, and triggering another event that plays a sound if the counter hits some value, you are applying abstract logic in it's simplest form. Increase the complexity only one level, say by adding a timer that starts when you first hit the button, runs for 10 seconds, and then only process clicks while the counter is running and the number of seconds elapsed rounded to the nearest second is even, is already taking things too far for most people. I'd love to see an example of an easy, visual way of implementing even something as trivial as this, that doesn't require you to learn about conditonals, arithmetic operators and control flow.


The UI itself or the code implementing it does not pertain to business logic or abstract concepts, but the stuff you control and display using that UI and how it interacts behind the scenes does, and you have to think about it to do more than just GUI storyboarding. That said, I think iOS, Cocoa, CoreData and XCode already do a pretty good job at relieving you from writing boilerplate code for these kind of things. You can basically create a GUI, a data model, a way to connect the two, and all navigation between different parts of your application, without writing a single line of code. Again, nothing new here. Start using all these tools, and in no time you will find out you need background about abstract concepts such as data model entities and relations, or queries, how persistency works, about data types and how you display and manipate them, what the difference between a float and an integer is, and why you need both, why you want to normalize your data model, and so on. All abstract concepts that you cannot hide behind some kind of visual tool that decides everything for you based on some widgets you threw on a form.


I'm glad you mentioned this, because I fully agree, and it's exactly this that has gotten me pretty far already. Over the years I think I've used at least 30 different programming languages, IDE's, compilers, platforms and frameworks. I'm not religious about the tools I use, not at the very least. When something better comes a along, I'm the first to evaluate it, if not because my current tools bother me, it would be out of curiosity or just for fun. I even bought my first iPad primarily because I wanted to learn objective-c, cocoa and iOS. So I'm not dismissing any tool that promises to allow you to write non-trivial programs without having to program out of conservatism, but just based on experience and observation. I simply don't believe in it.

Isn't this just a patent for iAd producer?

https://developer.apple.com/iad/iadproducer/

I would *love* something like this.

I think there are a lot of programing snobs who have the same attitudes that iMovie sucks because you need to go to film school to create anything worthwhile.

If nothing else, this could be a really great introductory tool for kids.

However, like Hypercard, it could be *much* more than that. I have a bunch of ideas for worthwhile apps that have very generic components, relying much more on the development of the media content to be associated with the app. I just don't have the time.

I see a lot of people up on their high horse here... and perhaps they're justified given the context: there have been countless failures towards this end. Still, I think there is a lot to be gained here if done right. Obviously, Apple has the resources and the talent to bring home the bacon.

The whole idea behind Object Oriented Programming is reusable modular architecture. I don't have to create button classes because they're already there, and that's a good thing. Similarly, I shouldn't have to painstakingly recreate common view layouts or the linguistic lubricant that allows each of these objects to interact so regularly from one app to the next, and that would be a good thing too.

The major reason this hasn't worked before is because it's been implemented as a standalone solution to programming (or blogging, where we have seen more success with this model), and the programmer loses some measure of control. This could be a real slam dunk if Apple properly implements this on top of the XCode platform as an additional, optional tool.

This is just the next obvious step in the evolution of programming.

It would get compiled to native code... It wouldn't run in VM like Java.

how can anyone claim all attempts at this failed? Hypercard was quite successful. Myst was created with hypercard and released in 1993. It went on to sell 6 million copies to make it the best selling computer game until the Sims passed in 2002.

Mishandling Hypercard is one of the bigger mistakes apple ever made. Here are some of the wide variety of apps Hypercard was used for


Creating commercial software isn't the only viable use for programming tools. If a programming system is easy enough that a small business owner can create custom apps to better run his business without having to hire programmers, it's quite useful. Who cares if you lose 5% more battery getting something useful done that you might have to lose if you hired progressional programmers to write custom objective-c code that that same small business owner has no chance of understudying or modifying.

Having an accessible entry into programming for children is also quite useful. That's what these portable tablet computers were supposed to feature when first envisioned by Alan Kay. I'm a professional programmer with 30 years of experience developing primarily for Apple products. The tools I use are too complex to teach my 10 year old daughter. Yet 30 years ago 10 year olds were programming Xerox Parc computers with no problems. A modern day Hypercard like product would be perfect for her. Something where you don't have to program all of the details, but can easily script objects where needed.

I build our website with javascript/php/mysql - I constantly wonder why that can't be as easy to program as hypercard. The results really aren't all that different. The tools for accessible programming are lightyears behind where they were 20 years ago.

I don't know whether you were including HyoerCard in this opinion, but I offer this. I was the sysadmin for 2700 Macs using Microsoft Mail, and our implementation used an Out of Office notification system that was built completely in HyperCard, both client and server side. Not only did it work pretty well for what it had to do, but it could be customised even further since it was an editable stack. I always thought Hypercard was a nifty programming environment, one that was as simple or as complex as your experience allowed.

10 years ago if you wanted a website you went to a web designer and paid them thousands of pounds to build it. Now you can buy software that lets you build a simple website in no time for very little cost. That's great for small businesses, local interest groups, individuals, etc who can now afford their own website. To me that's progress. If you want a more professional website you can still employ a professional web developer or learn to do it yourself.

I don't see why we can't have the same situation with iOS app's. I'm not suggesting my simple community project app would compete with professional app's or make my fortune, but it would open up iOS app's to a whole new audience in the same way that simple website building software did.

As for the sanctity of iOS developers well all I can say is that the iTunes store is full of badly written, buggy app's that have been developed by those same developers. Maybe some of the amateurs will make a better job of it.

Yes, but Apple can favour tools. If Apple proposes "X" as the default programming language, you'll see a lot of apps using such language.

Just the mention of Javascript as the suggested path by Apple produces me cold sweat.

It's fine to propose a tool for creating apps without code. But, if such tool lets you add code, then code in ObjectiveC, which is the technology behind Cocoa. It will be better for iPhones batteries, and also more coherent with the Apple technologies.

I more so mean the patent application...not the tool itself...I think the tool is a decent idea though I can see a flood of subpar apps in the appstore but then again since Apple is constructing the bones it'll probably look good.

We'll see.