Tag: Swift

Categories
Development

Just Code

Becky Hansmeyer: “For instance, I can take just about any Objective-C code and do a word-by-word translation to Swift that will compile and run, but it won’t be very “Swifty.””

The notion of being Swifty kind of bugs me. If you work in a language long enough you’ll naturally gravitate to language conventions or you won’t. If you’re an Indie, like Becky, I don’t think it really matters how Swifty your code really is. What matters is you’re willing to learn and adapt with the times and you can ship. If you don’t ship you don’t get paid.

I’m probably not very Swifty either, but I don’t really care. I can write code in Swift and it works just fine. During code review with my peers they’ll let me know of a more Swifty way of doing things so I can either make a change or get it the next time. I’m willing to do the new thing and I think that’s what we need to be willing to do if we’re going to survive as developers.

Be ready for change and adapt. That doesn’t mean you have to do it all on day one. Just be willing to make the change.

Categories
Development iOS Mac

Old Apps

A cute little monkey.I got an email from Apple a week or so back letting me know I needed to upgrade one of my apps to 64-bit. I knew right away it was Arrgly but wasn’t really sure if I wanted to update it.

On Sunday morning I received an email from an Arrgly user asking if I was going to update it because he likes the app. It felt good to know someone else found my goofy app useful. I decided at a minimum I’d publish a little framework someone else could use to write their own version of the app if I couldn’t get to it, or couldn’t finish it on time.

It took less than an hour to create the project and get it published. If you’re doing Mac or iOS development and you need to shorten or expand URL’s for a YOURLS based service you’re welcome to use YOURLSKit. It’s all Swift 3 but should be fine with Swift 4 projects and iOS 11 or macOS High Sierra. It’s a tiny bit of code, but it does the job.

Categories
Apple iOS Mac

Future macOS Frameworks

Duct Tape, fixer of all things!I stumbled upon an interesting conversation between some well know Apple Ecosystem Developers this morning discussing, maybe lamenting, the lack of UIKit on macOS. I’m afraid I may have pushed these fellas to take their conversation private, I am sorry if that was the case.

Here’s the tweet that started the conversation:

https://twitter.com/stroughtonsmith/status/779726806727491584

I’m not known in any development communities. I’m what you’d call a nobody. But I’m a nobody with years of experience that has seen changes to my development ecosystem.

Having experienced a dramatic shift in Windows Development technologies I have opinions about what I would expect to see from Apple. These opinions and $10.00 should be enough to buy you any item on a Starbucks drink menu. Take if for what it is. An opinion of a nobody.

What I Expect

Given Apple’s love and focus on Swift I fully expect Apple to put their effort into moving their frameworks to focus on Swift while continuing to allow App developers to use Objective-C with anything new. I’ve written about the idea of Swift only Frameworks. I believe we will eventually arrive there. For now we have excellent UIKit support for three different devices; iOS, watchOS, and tvOS. Odd man out would be macOS. It doesn’t make sense, at least to me, for Apple to spend time back porting or adapting UIKit to the Mac. Their bread and butter is their  iOS based trio of the phone, watch, and cable like device. Since iPhone accounts for around 60% of revenue it makes sense for the iOS Platform to be their primary focus. That begs the question, will the Mac ever receive the attention we’d like it to receive? Probably not.

In the end I’d expect Apple to push iOS forward while keeping the Mac as a primary development system for iOS, watchOS, tvOS, and macOS developers with the latter receiving very little attention from a new Frameworks perspective.

A Brief History of Windows Development

Like I said above, I’m opinionated and I’ve been around the block a few times. I know Apple isn’t Microsoft and people tend to hate those comparisons. But I do see similarities between the Microsoft of the 90’s and the Apple of today. That’s a discussion for another time.

The discussions around Frameworks reminds me of Microsoft’s transition to .Net and C# as an easier way for developers to create Windows Apps. Apple is making such a big push with Swift a new framework targeting Swift developers feels like a natural progression.

It’s taken over 15-years to really push app development into a .Net world. I suppose some could argue it took less than 10 and I wouldn’t fight that. The point is Microsoft managed to push an entire development community to a new technology while allow old technologies to continue to not only function but grow. Look at the Microsoft Office Apps and Adobe Photoshop among others. They continue to be very relevant today and continue to add new features while the Windows API receives much less attention than does .Net and C#.

Ultimately the point is I know Apple could choose to push toward a Swift only framework and allow legacy Objective-C/Cocoa apps to continue to grow and thrive. Microsoft is a prime example of how a company could pull it off.

I think it’s kind of nice being a new developer to Apple’s platforms. I don’t have 20+ years of baggage like I do with Windows. It’s been so much easier to move from Objective-C to Swift because of it. Well, that and being most familiar with C++ made the transition to Swift feel more natural to me.

Whatever Apple has in store for us, be it the growth of Cocoa, a new Swift centered framework, or a Swift only framework, I’m ready for it and welcome it.

Categories
Development iOS Uncategorized

It doesn’t matter

Medium: “It surprised me to find that the vast majority of the apps in the top 100 are still building without any Swift.”

This shouldn’t be a surprise. In the end nobody cares what language you use to build your app, especially if it does what you want, performs well, and has a good design. 

Some may say I’m an old guy, so I shouldn’t be taken seriously. I will tell you this. If it ain’t broke, don’t fix it. That’s the proper attitude to have when developing software. I’m not saying you should never rewrite a section of code. On occasion that’s necessary, but if code works and doesn’t need to be touched as part of a new feature, just let it ride. You’ll be fine. 

In the end it just doesn’t matter.

Categories
Apple

Core Intuition(@coreint) 209: We Need A Grand Gesture

I’ve been listening to Core Intuition with Daniel and Manton for a very long time. Being new to the Apple and iOS ecosystem it’s nice to hear from guys that have been around for a while. They have some pretty unique insights and experience to share with those of us new to community.

I feel like it’s time for me to give back a little. In Core Intuition 209, the talk a bit about Swift. With the advent of Swift, and Apple’s deep commitment to it, it’s tough as an old-time Objective-C developer to see and hear all the attention being given to the new baby. I’ve been in your shoes.

Back in the early 2000’s as Microsoft was making a big push with .Net and C# I was still hacking away on C++ applications written straight against the Windows API. Early on I had my doubts about .Net and C# becoming the development tool of the future on the Windows platform. Fast forward to 2015 and it is the dominant development tool. It just took a bit of time for people to become comfortable with the idea and, more importantly, it took time to people to trust Microsoft was all in with .Net.

I think something Apple has done a really good job of is convincing the development community they’re committed to Swift. It’s the only development tool at Apple that has really reached out to the community. They have a weblog and just this week released Swift to the open source community. Apple is committed.

Does it mean you should run out and rewrite everything in Swift? Probably not, but that is a choice you will have to make on your own. Apple has a huge investment in Objective-C and Cocoa and even if they stopped making huge advances to either it’s going to be years and years before writing code in Objective-C is not a good idea. In fact, Craig Federighi said as much this week in an interview with The Next Web.

“Objective C is forever. I don’t think anyone should fear for the future of Objective C. We’re going to continue to support Objective C for ourselves and the developer community.”

On Core Intuition the guys each said something that really stuck accord. Manton mentioned Swift’s syntax was a bit too punctuation happy, which I can agree with, and he says it reminds him of C++, which I also agree with. In my case I actually like the C++ language, whereas Manton said he’d rather not go back to it. I would never hold that idea against anyone. It’s an unforgiving language.

Daniel mentions his reluctance to add the Swift runtime to his products just so he can include a new class here or there. I had this same feeling when adding C#/.Net code to an existing C++/Windows API application. It just felt so weighty to get such little support. In those cases I’d say why change? Just keep hammering away in Objective-C if you’re good at it and you can move to release new product quickly. When building a new product give Swift a whirl.

Another great point discussed by Daniel and Manton was how people embrace new languages and find a way to over complicate things. Think about the Architecture Astronaut. Swift brings all kinds of interesting syntax sugar to the table, but it doesn’t mean you have to use it. Start simply, experiment. You’ll find things in the language you love and things you hate. It’s true of every language I’ve ever learned. Keeping your code readable and maintainable is way more important than any syntax sugar offered by the language.

I’ve been working in Swift for the past few months and we’re doing more and more at Agrian with it. All new features are being written in Swift. The language is expressive and once you get going I think you’ll find you can move pretty quickly. We still have large portions of code in Objective-C. We’ve been selective about moving bits of that code to Swift and other parts we leave alone.

If you’re an iOS or Mac developer I recommend you listen to Core Intuition. Daniel and Manton are thoughtful and very experienced developers. Listen and you’ll learn something new.

Categories
Apple Development

My Dearest Apple

If you’re a developer in the Apple ecosystem you’ve no doubt heard of Swift, and could be developing with it every day.

I work for a little shop focused on Agronomics Software and Services. Our service is like many gigantor services in thee market; a website with a backing REST based service. It’s a magical cloud! 

We also develop a mobile client for iOS. Our products are Objective-C based but recently we’ve been writing new features in Swift. 

Swift is a really nice language. It takes some getting used to and the syntax is super sugary. As an old C/C++ developer a lot of it feels right at home. We get to trade a dynamic language for strong typing, which doesn’t bother me in the slightest but might bug died in the wool old-time Objective-C developers. Anywho, suffice it to say I’m enjoying it, and I hope to develop in this language for many years to come.

You’re probably saying “What’s your point, man?”

What I’m trying to say is I hope Apple goes whole hog and gives us a new framework for application development. That’s right, leave Cocoa as it is, put it in maintenance mode and do everything from this day forward with a new set of frameworks built entirely in, and for, Swift.

I also hope Apple can bring more of the concepts learned from UIKit back to the Mac. We have a wonderful set or portable API’s with Cocoa, but the Mac feels a bit neglected. If a new set of frameworks were developed Apple could start fresh, leave out the cruft, and give us new frameworks built to take advantage of Swift’s language features.

Get your tools!I would imagine this idea makes app developers cringe. What about all those years invested in Cocoa? For years to come I would imagine Cocoa apps would receive plenty of support and still be first class citizens. Remember what Adobe went through to bring Photoshop to the Mac when Carbon was dropped? Yes, it can be painful, but knowing ahead of time Apple will eventually pull the plug on Cocoa would be helpful, if they ever feel like taking on such an ambitious project.

In 2000 (I think that’s the correct year) Microsoft brought us .Net with the C# programming language at a time when the Windows API (Win32 API) and C/C++ were the primary way to create great native Windows apps. This is what we used at Visio. Lots and lots of C/C++ with the Windows API, later on we introduced MFC into the mix, and finally after bein acquired by Microsoft we integrated Office shared components (MSOx.dll’s.) Microsoft to this day still writes in C++ for its Office apps but most development outside is now done in .Net in C# — I’m sure Microsoft is doing plenty of work in C# and .Net. It’s a very powerful framework and programming language and is getting the lions share of the attention. It was a big risk, but it has paid huge dividends for the Windows ecosystem.

This can be done, is my point. Apple did it with Carbon to Cocoa and Microsoft had done it with the Windows API to .Net Framework. It feels like we are primed for a new Apple Framework that embraces Swift.

Please note, I’m not suggesting that Apple should completely abandon Cocoa. If this type of change happens maybe they can keep parity between the two for a while to give developers time to switch. Remember, Carbon was released in 2000 and finally fully deprecated in 2012, it became way less useful in 2007 when it was not updated for 64-bit applications. Depending how you look at it, Apple supported Carbon for seven, or 12 years. If they allowed for a five year overlap of feature support before fully deprecating Cocoa they could allow developers to move into the new, completely Swift, framework.

Recently we have seen Dropbox fully embrace Swift. With the Dropbox V2 API the Dropbox team has dropped support for Objective-C. That speaks volumes. It’s obvious they feel strongly about the future of Swift.

Is a movement to an all Swift Apple Framework in our future? Your guess is as good as mine, but it is obvious Apple is embracing Swift as its language of choice for future software development.

Categories
Development iOS Mac

Swift, REST, and JSON

I’m fond of a site called The Pastry Box Project. It’s a collection of thoughts and stories by a bunch of great writers, but that’s not why I mention it. I mention it because I noticed they had a nice, simple, REST API. Nifty!

PastryKit

Since I really enjoy writing code that communicates with services, and I needed a little project to learn some Swift, I thought I’d write a couple classes, I call PastryKit, that implement the Pastry Box REST API in Swift.

PastryKit is just two classes:

  1. PastryKit – Allows you to communicate with the Pastry Box REST API.
  2. Pastry – This is an entry returned by a call to PastryKit.

You can read more about The Pastry Box API on their site.

private func showPastryBaker() {
     var pastryKit = PastryKit();
     pastryKit.thoughtsByBaker("mike-monteiro", completionHandler:{(pasteries, error) in
          if (nil != error) { println(error) }
          if (nil != pasteries) { println(pasteries) }
     });
}

The Heavy Lifting

Most of the “heavy lifting” is performed in one place in PastryKit.swift in the private getWithIngredient function. It makes use of NSURLSession, which was introduced in iOS 7. Go find that function if you’d like to see how to do an HTTP GET in Swift. This is a simple case, it doesn’t require any authentication, or messing around with headers, and it only does GET’s. Doing a POST, PATCH or DELETE would, of course, require some changes, but you get the idea.

    /// getWithIngredient - worker method that does all gets
    private func getWithIngredient(ingredient: String?, completionHandler: (([Pastry]!, NSError!) -> Void)?) {
        let url = ((ingredient) != nil) ? NSURL(string: PastryBoxUrl + ingredient!) : NSURL(string: PastryBoxUrl)
        let request = NSURLRequest(URL: url!)
        let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
        let session = NSURLSession(configuration: configuration, delegate: self, delegateQueue: nil)
        let task : NSURLSessionDataTask = session.dataTaskWithRequest(request, completionHandler:{(data, response, error) in
            if (error == nil) {
                var conversionError: NSError?
                var ingredientsArray: NSArray = NSJSONSerialization.JSONObjectWithData(data, options:NSJSONReadingOptions.AllowFragments, error:&conversionError) as NSArray
                if (conversionError == nil) {
                    var pasteries = Pastry.pastryArrayFromNSArray(ingredientsArray)
                    if (completionHandler != nil) {
                        completionHandler!(pasteries, nil)
                    }
                }
                else {
                    println(conversionError)
                    if (completionHandler != nil) {
                        completionHandler!(nil, conversionError)
                    }
                }
            }
            else {
                println(error)
                if (completionHandler != nil) {
                    completionHandler!(nil, error)
                }
            }
        });
        
        task.resume()
    }

Go Get It!

The code is available on GitHub if you have need to get stuff from The Pastry Box Project in your Swift or Objective-C app.

Enjoy!

Categories
Development Uncategorized

Regarding Swift

ZDNet: “In essence, Apple had one job — create a new baseline tooling for iOS and show a sympatico approach with how the rest of the industry actually operates — and they blew it.”

I don’t know anything about the author, but based on his statements I have to conclude he’s never written a line of production quality code in his life.

The last thing we need is a lowest common denominator language to allow iOS developers to make code that runs on other platforms. Ridiculous. We have the web for that. If you want a lowest common denominator experience, create a “responsive” website with JavaScript and be done with it. If you want the best experience, go native, with native tools.

Would C# be great on the platform? Yes, but there is no need for the .Net runtime because Cocoa gives us everything we need and it’s not garbage collected. No need for the additional overhead.

If you’re ok with the Xamarin approach, which is very nice, then you should, by all means use it. There may come a day when I’ll have to create an app that works for both iOS and Android and that may be the best approach, until then I’ll focus on learning the native platform tools so I can provide the best experience for my users.