Let's request Logos 4 Mac to be more Mac like 3) Ditch 'Mono' and 'go native'

Hi there - 3rd in the series "Let's request Logos 4 Mac to be more Mac like".

This time I'm suggesting (and I realise this may be a contentious point) that Logos - long term - ditch the current development platform being used to port Logos to the Mac, that is Mono (which is itself a port of the Microsoft development platform .NET) and to 'go native'. By 'go native' I mean use the Mac development platform to make (dare I say it) a real & proper Mac application.

Why say this?

The 'square peg in a round hole' syndrome. As much as I can understand the rationale (and good intentions) behind using Mono (code once, run everywhere) unfortunately I think the reality is that it ends up being a 'lowest common denominator' scenario. And the reality, which I read even the Logos Mac developers saying on the forums, is that they end up having to constantly tweak Mono to make it do the necessary things they need (and get around bugs not just from Mono but plus from .NET ?) to build Logos for Mac.
The developers (Logos) will possibly, and most likely, end up spending more time building and keeping afloat a Mono port of Logos 4 Windows then if they just bit the bullet and built the application using the Mac development platform in the first place.
Anyway, who said that .NET is a good development platform? I believe most developers would state that the Mac development environment and coding language is better than .NET.
The iPad. Pretty soon Apple's game changing platform the iPad is going to explode on the scene. And the Windows 'netbook' platform is not going to know what hit it. I believe (and I have no Apple stocks, nor do I work for Apple) that the iPad is going to be a major platform for content consumption - content like books, content like Logos produces. Companies which realise this and get in early will have an advantage. OK, I realise that once someone (like me) commits to the Logos platform and has investment in a lot of books then they are very unlikely to change. However... there are many other people, new customers, who may be looking for a platform for electronic reading of Christian material who will be looking at and buying an iPad and who will, eventually, look to see what is available on the iPad. Logos better be there, and with something substantially stronger than the iPhone Logos app. I would see an iPad app. which has the display 'front end' on the iPad which has option to connect via WiFi, preferably not (just) to Logos website, but also ideally to the customer's book database (on a Mac naturally). This means the iPad would display content, the (grunt) database searching would happen on the customer's computer which has the horsepower.

Ultimately my main point is that:

In the goal of trying to squeeze a square (Windows) peg in a round (Mac) hole Logos runs the risk, and that after expending a lot of sweat, of ending up with the Logos 4 Mac program being something which is neither Windows, nor fully Mac and which is not optimal. And (most certainly/highly likely) it will not be an application which takes full advantage of the superior Mac platform - which would be a shame. And which will not be well positioned to take advantage of the new iPad platform.

Find more posts tagged with

Comments

J.R. Miller

And which will not be well positioned to take advantage of the new iPad platform.

We already have an iPad app under development and have been working on it from the first day the developer pack was made available. The app is being programmed for the iPad and will take advantage of the IPad platform and what it does beyond iPhone. There is more written about this in the iPhone forum if you care to read up on what has already been announced.

Blessings

Patrick S.

https://community.logos.com/discussion/comment/98515#Comment_98515

We already have an iPad app under development and have been working on it from the first day the developer pack was made available. The app is being programmed for the iPad and will take advantage of the IPad platform and what it does beyond iPhone. There is more written about this in the iPhone forum if you care to read up on what has already been announced.

Blessings

Hi there - have looked through various of the posts on the iPad, I trust Logos will be able to build iPad version of Logos to take good advantage of the iPad platform.

The main thrust of my initial post though was regarding the Mac version of Logos 4 - I amended my the post to make that more clear. I am interested to hear thoughts from Logos development staff (if they can spare the time of course).

Terry Poperszky

This time I'm suggesting (and I realise this may be a contentious point) that Logos - long term - ditch the current development platform being used to port Logos to the Mac, that is Mono (which is itself a port of the Microsoft development platform .NET) and to 'go native'. By 'go native' I mean use the Mac development platform to make (dare I say it) a real & proper Mac application.

Have you looked at Logos for Mac 1.xx? That is a program that is pure Mac, built by Mac developers who were recommended by Apple. Can't get more native than that. As much as it pains me to so say, I use L3 in an VM window over it.

Based on that application, I will go wtih the Logos' current plan for L4Mac of shared back end code, accessed by different UIs.

As for the iPad. My only concern about the iPad and Logos is that it is going to be released while I am on vacation and hundreds of miles from the nearest Apple store. [:'(]

J.R. Miller

https://community.logos.com/discussion/comment/98528#Comment_98528

The main thrust of my initial post though was regarding the Mac version of Logos 4

I am not a developer, so I cannot speak to the specifics, but from the perspective of a user.. the Logos design approach which shares the same base code seems to have delivered a fantastic product so I see no need to change it.

Blessings

Keep Smiling 4 Jesus :)

With current Logos user base primarily running Windows, understand .NET framework choice. ( see Bob Pritchett's comments in http://community.logos.com/forums/p/9286/73865.aspx ) From a business perspective, do not anticipate Microsoft ever supporting .NET framework on non-Microsoft platforms. Likewise do not anticipate Microsoft supporting cross-platform on Windows.

Wikipedia has a Cross Platform article http://en.wikipedia.org/wiki/Cross-platform - includes "Write Once, Debug Everywhere" comment.

Once iPad version 2 ships (many months away), wonder about market share and Logos use base impact ?

Also wonder about Apple shipping a 22 inch touchscreen iMac this year ?

Dreaming: using my fingers on touchscreen iMac and iPad with Logos on both - sync notes, layouts, etc.

Keep Smiling [:)]

Jack Caviness

https://community.logos.com/discussion/comment/98534#Comment_98534

As for the iPad. My only concern about the iPad and Logos is that it is going to be released while I am on vacation and hundreds of miles from the nearest Apple store.

I live near an Apple Store. Send me your money, and I will pick up an iPad for you. [:D]

Terry Poperszky

https://community.logos.com/discussion/comment/98617#Comment_98617

I live near an Apple Store. Send me your money, and I will pick up an iPad for you.

And this helps me how??? [:P]

There is one 160 miles from were we will be hiking in Southern Utah, something tells me my wife won't look kindly me disappearing for several hours to run and pick one up.

J.R. Miller

https://community.logos.com/discussion/comment/98620#Comment_98620

BTW, for anyone who has not yet seen it, follow the link below to see a mockup of Logos on the iPad that is under development and should be released the same day the iPad launches

http://www.logos.com/ipad

Victor Gutierrez

https://community.logos.com/discussion/comment/98622#Comment_98622

I have found myself going back to Logos 1 for Mac again and again. The speed difference is unbelievable, and the whole thing is a lot more stable. Saying that, I still like the UI of Logos 4 better. I just think that Logos 4 is sooo slow and unstable. Searching something takes forever. The speed is not improving with the updates. That is after I indexed the whole thing (which took a couple hours.)

I am happy that the developing team is making strides to catch up to the Windows version, but I do not know how wise is to do it using Mono. I remember the whole "Java" craze. My experience was that it worked, until it broke for no apparent reason. Then it would take incredible amounts of time to fix it. My code became a mess of "patches." It was as if I was developing a web page that had to include fixes for every browser.

J.R. Miller

https://community.logos.com/discussion/comment/98657#Comment_98657

The speed is not improving with the updates.

Optimizing the program for speed will not begin in full force until we reach the Beta stage of development. We have to have the features in place before we can optimize. Hang in there, it will come.

Blessings

David Mitchell

Because this issue has been raised a number of times, I'm going to chime in. If this topic comes up again, feel free to link back to this post as the official and final word on the topic. While on some levels, the idea of a "fully native" application seems appealing, it is based on a number of false premises that I would like to dispel. Having done so, I hope it will be clear why we are on our present course.

To begin with, allow me to address the implication that our application is slow because we are using Mono. Typically, a user making this claim goes on to propose that we face the options of having a "slow" application that uses Mono or a "fast" application that does not. These options are a false dichotomy: this is not simply a choice between having a slow application or a fast application. If that were the case, we surely would have opted for a fast application! The choice is actually between having an application that uses Mono under the hood or having no application at all. Years of effort from many developers were poured into the development of the core of Logos 4. Were we to discard this work, it would take as long (if not longer--Cocoa is a rather antiquated platform, and lacks much of the richness of the CLR and C#) to recreate this core on the Mac. I believe that few of our users would be willing to wait this much longer for what would be, at best, a marginal improvement. For us to do so would be like burning down a house because we didn't like the siding anymore.

Additionally, there is the contention that maintaining Mono will cost us more time in the long run than rewriting the entire application from scratch using only Apple's tools. Nothing could be further from the truth. As I have already stated, the cost to rewrite this software could easily be measured in years, even with a team of our size. We presently have one or two people who occasionally look into making improvements to Mono. There is no contest between which option is less effort.

Finally, there is the issue of whether or not Logos 4 for Mac is somehow "less native" than other applications. What does it mean to be a native application? Does "native" mean that we are not using JIT-compiled code? Even Apple is now recommending this approach--they now prefer that developers use gcc-llvm and clang, which both use JIT. Generally, when people refer to a Macintosh application being "native", they mean that it uses Cocoa (or Carbon) for the UI layer. This is precisely what we are doing: we may have lots of common code that runs using the Mono runtime, but every pixel you see rendered to the screen is rendered using Cocoa. The entire UI layer is written in Objective-C, using Apple's tools. While you may at times feel that a particular piece of the application doesn't feel quite right, this has nothing to do with our use of Mono and everything to do with the fact that this product is still in Alpha, and there are still some issues that have not been completely settled.

In conclusion, there are no compelling reasons to throw away the years of work that we've already invested in writing a top-notch digital library product, and many reasons to do everything that we can to preserve and improve it. Once we have more of the core UI in place, we'll begin performance tuning, and then you'll see it really begin to shine--users who participated in the Windows beta can tell you how much it improved during that period!

We're building the Mac product on a solid foundation based on years of development effort.

Bob Pritchett

David's explanation is excellent, and correct. And I love the "burning down the house because we don't like the siding" analogy. :-)

All cross platform applications present problems. You can choose to code the app from scratch on both platforms, using native practices and technologies on each, and then spend all your time on making your app work the same. For some apps, where the two platforms never touch, this can be okay. But if you share file formats or (worse!) synchronize data, you'll spend all the extra debugging time on making the data identical.

Every time we add a property to a file format, or a new data type to sync to the server, we get it "for free" on Windows and Mac, and we absolutely know they're reading and writing the same data. Because it's the same code.

Our previous experience taught us that writing two apps that read the same books (all 10,000 of them, built over 10+ years with multiple generations of the compiler) is nearly impossible. (Not to mention ensuring they display them the same on screen!)

So yes, we have to address .NET/Mono incompatibilities. But this is easier than addressing "two implementations of the code to read/write all of our data formats, which change constantly".

The iPad code base is based on the iPhone code base, which was written completely native with no shared code. We can't use .NET there, but I'm already regretting that we let it be a completely new "native" app, rather than forcing that team to keep our existing layout and display code. We have lots of books with subtle display issues, small difference in how our desktop and iPhone render things, etc. We'll probably end up re-doing that part with a very "line for line" port of our display system. It won't be .NET, but it'll be "the same code".

Adobe and Microsoft (and even Apple) all have the same issues, and we've watched them take varying strategy. They each have strengths and weaknesses; we're just goign with the one that seems to work best for our application.