Tag: iOS

Categories
Development

Irrational Rob

I love writing software. I especially love writing my own software. When I’m doing my own thing the day zooms by. I’m energized afterward. Ready to get back to work on it.AHHHHHH!

I’ve been doing iOS work for quite a while now and have always wanted to do a native Mac app. Of course SwiftUI will allow me to do that fairly easily.

Here’s the thing. There is this super irrational me that wants to put apps on iOS, macOS, Windows, and possibly Linux. Maybe even Android, who knows. The first three targets for sure; iOS, macOS, and Windows. To that end I keep plugging away on my own C++ class libraries. Recently I started refactoring them. I love the way UIKit/AppKit are built, so I’ve modeled what I’ve done thus far after those Frameworks. It’s still very early days but I’m enjoying the process.

There is the irrational Rob. The one that wants to build his own class libraries so he can write one hunk of code in C++ that works on different platforms.

Recently I asked a friend for advice about how he’d implement a dictionary class. His answer was simple, and the proper one: “I wouldn’t. I’d use std::map because it’s a dictionary and I’d use std::vector because it’s an array.” Of course he’s correct! It’s completely irrational for me to do this stuff, yet, I’m still going to do it.

Why? Because I can and I want to.

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
Apple iOS

UIKit for Mac

mar·zi·pan
[mahr-zuh-pan]
noun: marzipan

  • a sweet, yellowish paste of ground almonds, sugar, and egg whites, often colored and used to make small cakes or confections or as an icing for larger cakes.
  • a new Apple Framework for building Mac and iOS Apps from the same source code.

A unified Apple Framework makes sense. By this time AppKit is fairly old, it began life at NeXT and moved forward as Apple’s new framework on macOS. When Apple created iOS it made sense to reconsider the user interface and user experience for a touch based interface. Having support for mouse clicks and menus didn’t make a lot of sense for something so small controlled with your finger. Enter UIKit.

To say iOS became a shooting star, Apple’s crowning achievement, would be an understatement. It’s wildly popular amongst users and developers alike. So much so Apple has kind of pushed macOS into the background and allowed its younger brother to take center state. It’s not that macOS isn’t popular — because it is — it’s just that iOS is much, much, bigger than anyone could’ve estimated. As a result Apple spends most of its time working on iOS, or at least it seems that way.

In the episode Marzipan: Apple’s Next Big Software Thing! of Rene Ritchie’s VECTOR he discusses Marzipan with a lot of well known developers and writers. None of the folks go as far to think Apple could be making a monumental leap forward with Marzipan. What if Apple goes all in on a brand new framework completely written in Swift? I know it’s not likely to happen, but what if it does?

Obviously that would be hugely upsetting for the Mac and iOS ecosystem. But on the flip side it would give developers a clean slate to work with. Something designed to work for touch and mouse and keyboard input. It would give Apple the chance to shake off years cruft and reimagine applications and frameworks without the constraints imposed by Cocoa or Cocoa Touch.

Am I crazy? Yes, a little. I know current developers — especially Mac developers — would lose their minds. It would be the second time Apple changed direction on them in a potentially radical way. This wouldn’t be quite so egregious. The move from Mac OS 9 to Mac OSX was monumental. A brand new OS and a brand new way to code, not easy to adjust to after years of working with an OS and API. Carbon eased folks into it, but the transition was still extremely difficult for some development shops, like Adobe.

Duct tape. Fixer of all thingsOf course they don’t have to go all in. I doubt they’d be that extreme. There are simple things they could do to unify Cocoa and Cocoa Touch. An extremely simple example I can think of is unifying NSColor and UIColor. Over time we’ve seen some text attributes move to their NS* counterparts, why not start with the simple things and work down the stack?

I also don’t consider going from iOS to macOS cross platform. I know they’re slightly different but they are in the same family. If you’re doing iOS development macOS should feel somewhat familiar to you. Sure the controls are different on the platforms and there’s the matter of touch vs. mouse driven, but I believe calling Cocoa based applications cross platform between Mac and iOS is a bit of a stretch. If you’re taking one set of code from iOS to Windows that is what I’d consider cross platform.

Post WWDC 2018 Thoughts

Eat your own dog food.I penned everything above quite a while back, March 11, 2018 to be exact.

While on stage at WWDC Apple announced UIKit for Mac. Four UIKit for Mac applications will ship with macOS Mojave this fall; News, Stocks, Home, and Voice Memos. This is great news for anyone interested in bringing their own iOS Applications to macOS. It means Apple is dogfooding UIKit for Mac while it’s in active development. From all reports it’s really rough around the edges but we can all hope some of those edges are smoothed out before Mojave makes its debut but it’s ok if the applications and framework are a bit rough at first. Why? Apple said on stage UIKit for Mac wouldn’t be generally available until 2019 and that it was a multiyear project. This tells me we should expect a gradual move of UIKit downward into AppKit until UIKit either becomes a part of AppKit architecturally or the Mac specific bits of AppKit become a part of the “new” UIKit for Mac.

In many ways it feels like UIKit for Mac is the right direction. It’s been running on macOS for 10 years. If you’re a developer you’ve used the Simulator everyday to run your iOS Apps on your development machine.

UIAlertController
Definitely not what you want to see on your Mac

Any developer will tell you shipping software is difficult, especially if you’re driven by deadlines and not feature sets. Given Apple have already announced four applications shipping with Mojave they’re going to have to make really tough decisions to make sure these select applications are ready by fall. It seems reasonable to expect these first UIKit on Mac applications will have a decidedly wonky feel, not quite native. There will be telltale signs, little things, that drive native app seeking people crazy. Things like seeing a UIAlertController instead of an NSAlert when an app needs to inform you of something or ask a question. It makes the application feel unnatural.

 

Getting an error on your Mac can be frightening but at least this alert feels like it belongs on the platform.

At the beginning I’d expect UIKit for Mac to either reach down into AppKit to do the work or reach under the hood and use the same lower levels AppKit uses. Conceptually this is how UIKit living on top of AppKit looks. It’s a way to bootstrap your new Framework into being. Leveraging what AppKit already does seems a reasonable way to just make it work.

UIKit living off of AppKit like some kind of digital vampire.

As time goes by I would expect more of AppKit to move upward into UIKit. UIKit becomes the new preferred framework for building applications on Mac. Maybe it gets a new name? Maybe not? As that transformation begins taking shape we’ll see UIKit itself transform to feel native on each platform. Mac apps will feel like Mac apps and iOS Apps will feel like iOS Apps. It’s not rocket science. Applications for each OS should feel like they belong. No compromises. Hell, we can write Electron Apps if we want compromise.

UIKit consumes the heart and soul of AppKit becoming the ultimate application development platform for Mac and iOS Apps.

As Craig Federighi pointed out on stage at WWDC this is a multiyear effort. Expect things to be ugly at times from the user perspective and the developer perspective. In fact I expect it to be the development effort going forward for iOS and Mac UI Frameworks. Until — of course — the next shiny framework comes along.

Categories
Apple Microsoft

Swift, on Windows?

Brent Simmons: “What if — and it’s a big if — Microsoft made Swift a peer with C# and provided some good app frameworks?”

When I published What Ifs and Why Nots I hadn’t read Brent’s piece. He’s actually asking the same questions. What would it take to pull Mac developers to Windows? It would take more than Swift, I’m pretty certain. In a Microsoft .Net world where would Swift fit? Would Microsoft just create a version of Swift that works with the .Net garbage collector, or would it be a compiled language? I’d bet on the former given Microsoft’s all-in on .Net and garbage collection.

The bigger questions is Frameworks. Let’s just say Microsoft does a .Net version of Swift. To create a Windows application you’d have to embrace WinRT. You could use your knowledge of Swift, but you’d have to learn a completely new way of writing applications.

Think about all the things Foundation does for you. If you were to move to Windows and Swift on Windows was all .Net based you couldn’t even reuse your non-UI based classes. You could, of course, reimplement your shared classes to use .Net stuff and maintain your interfaces, but you’d have to do a considerable amount of coding to fit on the platform.

Maybe you don’t make Swift a .Net language. Maybe you bring Foundation over to Windows using the Windows API, which is very different from a development standpoint, and not the preferred way to code new apps on Windows. This could also work. You would have a compiled Swift that could natively link to Foundation, which in turn uses Windows API’s to do any platform level stuff. You could then reuse some of your code investment, like those shared non-UI classes and work on creation of a native Windows UI for your application.

Also, of note. Microsoft already has a great set of Frameworks to use, just use them. It would be like coming to the Mac from Windows and saying “Apple needs to provide some good app frameworks.” They already do, you just need to learn to use them to make the best experience for your users. That is the biggest hurdle for any developer.

Learning the new frameworks and a new OS can be quite daunting. When I came to iOS from doing Windows and Linux based UI’s (using Qt mind) I fought with Interface Builder and decided I had to do everything in code because I couldn’t figure it out. Later I made my peace with it. I still think Visual Studio is the better development environment, but Xcode is a very close second, maybe tied, at this point.

Eat your own dog food.I’m kind of a knucklehead. I spent almost 20-years doing native Windows API based applications so I was very comfortable with Visual Studio and that entire ecosystem. If I can learn to write iOS Applications and embrace the tools, then anyone doing Mac or iOS apps could learn to do Windows based stuff today. Just embrace it, don’t try to force your tools into the platform. Now, if you have some code that can easily come over, you might as well use it, but we all know the best apps feel right on the platform. Embrace the platform.

The new Surface Studio is the first bit of Windows based hardware that has excited me this much about the platform in a very long time. I’d love to work on a new design app for Windows, if I could. Maybe even one that works on both platforms; Windows and Mac. Why not? I mean besides time and money, what else does one need to do something so ambitious? 😀

Categories
Apple

Xcode on iPad?

This is another interesting idea, if only to ask why? A lot of developers have a habit of doing things “because.” It’s not a bad thing, it’s usually out of curiosity or because it’s a fun challenge. Now, I don’t believe this is why we’d get Xcode for iPad, but initially it felt that way.

The obvious question is “Who is this for?” At first I thought it was a silly idea, but after letting that question stew for a while I decided it wouldn’t target Professional Developers, it would target hobbyists.

Imagine if you will an Xcode stripped down to Swift only, hopefully with a new Swift based framework for modern development. Playgrounds would be a bright spot for curious folks. There’s no need to go whole hog with all of Cocoa and Objective-C, give everyone a clean slate environment for the creation of iOS Apps. 

If you look at all of Apple’s recent hardware creations they have their own operating systems. Each operating system is honed for the platform and each in the mold of iOS, not the more open OS X model. 

If you remove OS X as a development target and only target Arm based architectures the idea of a trimmed down Xcode begins to make a little sense. You should be able to build all targets on an iPad Pro. Keep in mind the A9x performs really well. 

I still believe for serious development you’ll need a keyboard and mouse. We will see if Apple ever finds it necessary to create what I’ve dubbed macOS or do developers shoe horn their workflows into a less capable workflow?

According to John Gruber we may find out at WWDC 2016. I hope I will be able to attend.

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
Apple

That’s a big NO for macOS

Cult of Mac: “We don’t believe in having one operating system for both mobile and PCs (like Microsoft),” he said. “We think it detects from both.”

He got a smattering of applause for that.

“We have no intention to blend them.”

I think that kills off the idea I had of seeing an iOS like macOS on the MacBook. I’m OK with that.

Long live OS X.

Categories
Apple

Is the future macOS?

If, like me, you’re an Apple fan you know they announced a bunch of new products on Wednesday. It seems apparent to me the future is based on the iOS codebase, not OS X.

We now have iOS, watchOS, and tvOS. I may be wrong, but I suspect watchOS and tvOS are derivatives of iOS. It makes sense. When Apple created iOS they started at the bottom layer of the OS and worked their way up. They reused the Kernel and Core Foundation. On top of that they added UIKit and a touch layer to give us the unique experience we get with iOS today. The important thing to note is the OS was stripped down and made to fit the device it was built for, by fit I mean the feel as well as the size of the OS.

With iOS Apple took the opportunity to tighten up how applications could interact with the operating system. It’s still a very powerful OS, but Apple removed all the power user features. The ability to peek under the hood is gone. As a developer we’re no longer given access to all parts of the computer. We all get our own little sandbox to play in. This was all done so bad people couldn’t turn your phone into a virus factory. In other words, it was done in the name of securing the device, making sure it would always work. It is Apple’s most secure operating system, and that’s saying a lot given OS X’s reputation.

Yeah, AppleWhy all the talk about iOS? Well, I think it’s the future of the desktop. With the introduction of the iPad Pro Apple is beginning to blur the line between tablet and desktop. It’s the first hybrid device for Apple. We all know Microsoft created the Surface years before. Where Microsoft took the approach of bringing a full desktop operating system to the Surface, Apple decided to begin with iOS and work up. Folks will say this will make iPad Pro less powerful, I don’t think so. How much “power” do you need? It’s not as if people really care about technical specs when they buy computers, right? Well, if you do, iPad Pro is more than capable.

Bringing laptop class power to a tablet has fueled speculation that the Mac could move to ARM processors, or maybe it’s better to say OS X could run on ARM.

Rich Siegel via Twitter:

It’s not a stretch to believe OS X will be completely ported to ARM — remember iOS shares core code with OS X. In fact it may already run on ARM processors.

That brings me to the point of this post. I’m beginning to believe iOS, and Universal Apps, are the future of everything Apple ships. Not only will OS X be ported to ARM at some point, I believe we will see an Apple laptop based on ARM processors running iOS. It will be the familiar clamshell design we’re all familiar with but will have a touch screen, full keyboard, trackpad, and you’ll be able to pull the display part away from the base (keyboard.)

This is how I believe Apple unifies its story. We have iOS, watchOS, tvOS, and in the future macOS. With macOS being the version based on the iOS App ecosystem. OS X will continue to live as the power user option in the Apple lineup.

For many people it would eliminate any confusion over the difference between OS X and iOS based App Stores, as Daniel Jalkut pointed out in a recent Twitter post.

How long before we see the new macOS?

Why, oh why, would I believe that? Well, it seems like a natural evolution of iOS. When iOS first shipped it was a tiny OS, over time it has grown to add more and more rich features, but it remains quite tiny, very secure, and built to serve a new model, an easier model. Couple that with new features of iOS 9, like split views and picture in picture, and you can see the OS moving in a new direction. We’re at the crux of applications cooperating with each other to create unique experiences. This isn’t new, far from it, but it will be reimagined on iOS. It will give us the power we’ve been looking for and maintain all the security we’ve come to love. That’s why iOS is so valuable.

Think about “the average user” of a computer. I’m not talking about super-geeks, like my brother that need those super power user features a lot of developers enjoy, I’m talking about folks like my wife. She is a gamer and uses her home MacBook to play games, surf the web, answer and create email, and play games. On occasion she will compose a document using Pages. This type of use would be fine for an iOS based device.

The iPad can also be used for day-to-day use. Federico Viticci uses an iPad as his daily driver and swears by it. I have to believe the iPad Pro will be a welcome addition to his daily workflow.

We should also keep in mind the partnership Apple formed with IBM to create solutions for the enterprise. This is how Apple rounds out its offerings for businesses. Get a third party to make the iPad attractive to businesses.

Oh, yeah, and one more thing. Tim Cook loves his iPad!

In the end could you imagine how wonderful a Mac laptop would be running a form of iOS built just for the hardware? Something that is essentially an iPad with the addition of a keyboard and possibly a mouse? It feels like the Mac could evolve in that direction.

Categories
Apple

Don Melton on Debug 69

I was hoping we’d hear from Don Melton on the idea that Safari is the new IE and he didn’t disappoint. For those that don’t know Don is the man that started the WebKit and Safari projects at Apple. He’s also a former Netscape developer so he’s been around the web and web browsers for a very long time. If you have some time go listen to Debug 69, it’s a bit explicit, Don like to drop the F-bomb, but it’s also very informative.

Two things stood out about how the Safari team approaches development of new things. They really care about security and battery life, since mobile is now king. It’s apparent they introduce features quite a bit more slowly than Google. That fact goes a long way to explaining why Google forked WebKit to create the Blink project. They wanted to move faster and felt held back by Apple’s WebKit team.

UPDATE: 7/25/2015 – I sent a link to Mr. Melton via Twitter and he graciously took the time to come read this post, which I really appreciate. Afterward he provided some excellent feedback. Here’s a correction to the statement above:

Something I’ve been an advocate for is the implementation of the ECMA CLI in all web browsers. It was interesting to hear Don talk about the idea of Web Assembly, which is the new push to make languages that convert down to JavaScript so you can write in multiple languages on the web (which is why I’m a fan of a CLI implementation, we could have C# on in the browser, nifty.) Don’s take made me reevaluate my position. Why not let websites be websites and let applications be applications? Both need HTTP and the web. I’m a fan of web services and that is definitely the new backbone of any application development today. A lot of applications, be it in the browser, or native, depend on web services to do their job. The application I work on daily is no exception. At Agrian we have a web application and a native iOS App backed by a web service. The native application was created because Agrian wanted to create the best user experience they possibly could, not to mention provide a great offline experience. Our application is used by farmers that are often out in the country side, and often without connectivity. Changes are cached and synchronized when the farmer has a connection. It provides a good experience all thanks to the ability to save while offline and push changes to our web service when the time is right. Wow, sorry, went off the rails there.

The point is, I’m not sure making the web browser do everything you can do on the desktop is the right thing to do. Let the web be the web. If you want to do a native application embrace the platform and do the best possible job you can for your users. This holds true for Android or iOS. Both provide great SDK’s built to take full advantage of the platform.

Go forth and create.

Categories
Development Indie Life

For Love of Apps

A wonderful bouquet of flowers.
Brent Simmons: “This is the age of writing iOS apps for love.”

This is what I’ve decided to do; write iOS or Mac apps for the love of it. If the app succeeds, great! If it fails, that’s ok too.