Fun with Fred and Barney

Steve Mann and MACAPP3TECH$

Gee, with a name like Bedrock would we be talking about a TFred class, a TWilma class, etc.?
- Kirk Austin, ILM

Since the last FrameWorks went to press, there has been a lot of AppleLink traffic discussing Bedrock. The most heated discussion so far took place on the MACAPP2TECH$ and MACAPP3TECH$ AppleLink group addresses. In addition, there is an ongoing discussion in the AppleLink Developer Support bulletin board (Developer Support: Developer Talk: Macintosh Development Tool Discussion: MacApp Discussion Folder) about the viability of MacApp3.

We thought it might be appropriate to include some of this electronic activity for those MADA members that don't have access to AppleLink or don't belong to the MACAPP2TECH$ or MACAPP3TECH$ group addresses. These messages, presented in chronological order, are all culled from those two group addresses,

A few recurring themes stand out in this series of links:

• Bedrock source code availability-Many MacApp developers think it's essential that the Bedrock class library source code be available.
• MacApp 3.X support from Apple-There is concern that MacApp 3.X will not be upgraded to fix known bugs, that there will never be even a MacApp 3.1, and that current MacApp developers are essentially being stranded with an orphaned technology.
• Porting MacApp applications to Bedrock-Developers want to know just how useful their MacApp knowledge will be for Bedrock, and what tools will be available if it is possible (unlikely) to port MacApp code to Bedrock.
• The Yet-Another-OOF (Object-Oriented Framework) Syndrome - First it was MacApp 2.0, then 3.0, now Bedrock, all in relatively quick succession-when will it stop? How does Pink fit into this sequence?
• How strong is Symantec and Apple's commitment to MacApp developers and the timely delivery of information to those developers?

On that last theme, Symantec has a telephone number (408/446-8931) you can call to apply to join the Bedrock early developer program. If you leave an appropriate message, they'll send you an application. Included with the application questionnaire is a copy of the Bedrock press release, a Bedrock white paper, and a overview of the development tools market. Symantec is collecting names and basic qualifications for those people they hope to anoint as early developers.

Gordon Apple at Advanced Communications Engineering (one of our FrameWorks authors this month) found the telephone number on Compuserve. As one of the links in this collection indicates, Symantec has an active forum on Compuserve, none on AppleLink. This focuses the last item in the list above a bit more-what is Symantec's commitment to MacApp developers?

Symantec clearly wants to penetrate the PC development tools market. They also have their own developer group for Think Class Library users. Sources at Symantec have essentially said that selling Bedrock to MacApp developers is like preaching to the already converted. All of this suggests that on the priority list, MacApp developers are perhaps third or fourth on Symantec's list of preferred partners, which is unfortunate. Perhaps they forgot that religious wars are bound to fail if the zealots lose their zeal.

So far we've seen a lot of advance marketing and hype, but very few specifics. Most of the MADA members I've talk to are skeptical about Bedrock. Until Symantec and Apple provide developers with answers to some of the questions posed in these links, that's not going to change. In the mean time, this collection of links, courtesy of MADA members, may give you some insights into some of the choices that you may be facing in the future.

Sub: Re: Bedrock 'n stuff

Gee, with a name like Bedrock would we be talking about a TFred class, a TWilma class, etc.?

Kirk Austin, ILM

Sub: Bedrock Packaging

It seems to me that the break from MacApp & TCL provides an opportunity to market the source separately from the libraries. There are surely many programmers, both professional and amateur, who never need to refer to MacApp's source. (Just as there are many of us who make a living from our ability to navigate the backwaters of MacApp.)

I would like to see Apple/Symantec sell a basic package (no source) for something like the current price of Think C/TCL. This could get a lot more programmers on the O.P. bus (probably a "good thing") particularly on the Windows side.

A separate source package on CD-ROM could sell for (say) $250. It would be available only to registered owners of the library version and only direct from Apple or Symantec.

And of course there's the combo box with both parts at a small discount.

I think the most important thing is to find ways to make this stuff available to the largest possible number of people. So, Apple Marketing Folks - let Symantec set the price.

Bill Colsher
SKAMP Computer Services

Sub: Bedrock source is necessary

We would never have been able to ship our two products (OmniPage Professional and OmniPage Direct) if we had not had the source to MacApp. MacApp contained so many bugs, that without the ability to correct the problems in the source we would STILL not have those products on the market. When a program, like MacApp, becomes the basis for application generation it is imperative that the application developer be able modify/customize the source for their own needs. There still are bugs in 3.0 final that we reported in 3.0b2...

Without source I cannot justify the use of a product like Bedrock as a foundation for our product family. It is much more important to me to be able to release bug-free applications on time than it is to have a common UI code base and be unable to get an application through our QA cycle.

Wade Eilrich
Manager of Macintosh Projects
Caere Corp.

Sub: Re: Bedrock source is necessary

Yabadabadoooooo!

There is a curious paradox in the debate over source. Let's assume, for the sake of argument, that the product works flawlessly in all its versions, or that Symantec's support is sooooo great that it doesn't matter, since they'll fix it in a flash anyway. The whole area of QA for class libraries is a quagmire of conflicting strategies and utopian visions. And let's assume for the sake of argument that the documentation is picture-perfect and kept perfectly up to date. It won't happen - witness the forthcoming "quick reference" for MacApp, which documents a fraction of the whole in 600 pages - but let's just assume that it can and will happen. Now, do _we_ still need source? Is it still in the _vendor's_ best interest to release the source?

Polymorphism is the cornerstone of code reuse in OOP, and to take advantage of it a well-factored object-oriented designed decomposes methods into, ideally, one to ten lines of source per method. So in one sense, it doesn't matter: if the documentation is really good, it doesn't take a rocket scientist to figure out what the source must look like. And if you can't guess at it, anyone who ever took a course in assembler language can drop into a debugger and know for sure.

One then has to question the worth of the documentation in the first place to the extent that it reproduces the algorithms of the code. (At this level of granularity, let's not get caught in silly semantics: usage protocols imply algorithms at some point.) C++ is nice and succinct. Ever try translating simple for loop logic into equivalent English (or whatever)? Natural languages are anything but succinct. Why turn what to a programmer is a precise expression, code, into something imprecise written by a technical writer who doesn't code or, worse, a coder who doesn't write? It mushrooms and distortion is always introduced. And that's before you start making changes over the life of the product.

Another observation: stolen OOP code doesn't go far. Classes, for all of our bellowing about reuse, tend to be pretty well tied to the class library they come from. Furthermore, the only people who can really take advantage of stolen source are other big companies whose lawyers will jump up and down and scream at the thievery. So it doesn't strike me as in a vendor's interest to tie up source, since the source is likely to be reused only within that vendor's product, anyway. There are exceptions, chiefly in low-level stuff like code generators and real-time kernels that represent heady investments in discarding other alternatives, but most OOP code is just straightforward implementation of stuff that is in the manual. In fact, one could argue that really great OOP documentation just makes it _easier_ for someone to pirate by reverse engineering to the same interface, rather than browsing copyrighted code.

So, in summary: It doesn't strike me as in the programmer's interest to see documentation only, since that is always more verbose than the equivalent code and far less precise. It doesn't strike me as in the vendor's best interest to not release source, since it means a heavier burden of QA and support, a heavier - perhaps impossible - burden of documentation, discouraging innovation from the user community that can lead to better future versions, and frightening away people with mission-critical projects that have to be controllable, in the worst case, from within.

Regards,
Jeff Alger

Sub: Frameworks and the Toolbox

It seems like a good time to resurrect a topic from the WWDC, namely what priority is Apple placing on supporting new features in their object framework.

For example, Quicktime, in its initial form, is not entirely compatible with MacApp. If, as Apple says, object frameworks (i.e., MacApp) are the recommended way to write Macintosh apps, the object oriented interface should be as important as the Pascal interface for Inside Macintosh. At the WWDC there was a lot of finger pointing. The MacApp team said the groups extending the toolbox should guarantee compatibility with MacApp. The other groups normally said the MacApp team should do it. I came away with the impression that there was no real corporate commitment to timely support new toolbox features in their object framework. To be fair, the MacApp team has done a good job with System 7, but when will MacApp fully support Quicktime, the new technologies discussed at the WWDC, and future enhancements?

Now with Bedrock, framework development seems to be shifting from Apple to Symantec with help from Apple. This is not supposed to be a least common denominator solution, but what happens to features beyond those common to GUI's? I assume Bedrock will support technologies Apple decides to port to Windows (e.g., Quicktime), but what about the unique things on each platform? How much framework support can we expect for state of the art technologies, and how long will we have to wait to see it? A greatest common denominator solution is not a good choice either. The framework will have to be different, at some level, for each platform supported. Otherwise, we're all back to reinventing new wheels everytime Apple or Microsoft releases a new technology.

If Apple is really serious about the greater development community moving to OOP, I think they should make a public commitment to support their chosen framework to the same degree they support their other development environments.

Looking for a soup spoon,
Nick Nallick

Sub: Re: RE: Bedrock source is nece

One of the most compelling arguments in favor of distributing source code is the following situation: Sometimes I want to override a MacApp method, just making some subtle change in the code. It's much easier to copy and paste the whole method and then make my changes than to try to reconstruct the method from nothing.

I can think of several instances where my job would have been next to impossible had I not had access to the MacApp source code.

- Mark

Sub: Re: Bedrock source is necessary

Clearly, the line is drawn according to the quality, stability and complexity of the software.

Can you write a MacApp application without source? At no point in my exposure to MacApp have I ever thought anything but 'no'. This is generally because of the quality/complexity of both the library itself and of its documentation (the line about the MacApp source being the documentation is true).

To use an example from another world, although source for Motif is available from OSF, many platform vendors that supply Motif do not ship source, because you do not need source code to run/compile a Motif application, and presumably they don't want to publish their vendor-specific code.

Howerver, the question is: can you write a Motif application without the source? The emphatic answer is: NO. Can you port a Motif application to a new platform without Motif source for that platform? The answer is: Probably.

So far I have begged the question of whether I need the source to the toolbox to write an application. Let me answer the question by saying: no, I don't need the source, because I don't 'use' the toolbox. I use MacApp, whose job it is to isolate me from the details of the toolbox. Other reasons why I don't need the source: much stabler interfaces, much stabler implementation, much stabler documentation, etc.

Have I ever wished I had the source to the toolbox? Have I ever crashed inside the ROM and wanted to be able to step in to see what was happening? Would I have been able to find some bugs in my code faster this way? Yes. Do I require the source to the Toolbox in order to write applications? No.

I'm not against a pricing structure that charges extra to acquire the source code, but I think it would be ill-advised not to make the source available at all.

anders

Sub: Don't show the source code

Buggy code and confusing implementation) *have* been some hallmarks of MacApp (and every other development tool ever written.) Source code availability has helped all of us overcome some of these problems. If we weren't able to overcome these problems, MacApp would have either (1) died or (2) gotten some additional engineering resources.

Not having source code available forces better encapsulation, a clearer object model, and encourages managers to invest engineering resources because those engineers are creating something proprietary.

I think documentation is probably not as important as overall design and power. Understanding the MacApp command chain (forgive my 2.X ref's, I'm not 3.0 fluent) might require quite a lot of documentation and training without source, but isn't a possible solution to make posting and reading commands simpler (semantic object model everywhere?) instead of providing tools to understand something (unnecessarily?) complex.

I'm not sure that Bedrock will be *it* and it may be cheaper to provide source than provide all the engineering support that might be needed to make it work without source, but the future must be sourceless if vendors are going to stake their companies on the development of these frameworks.

Aaron Rosenbaum
aaron@gamma.com

Sub: Source vs. Commitment

Yet another opinion on the framework source issue...

For me the question of whether or not source is required for a framework comes down to the level of commitment from the provider. Providing the source is the easy way out for a vendor. Compare the toolbox with MacApp:

• Quality Assurance.
  There is no contest. MacApp final versions probably contain more known bugs than the unknown bugs that turn up during the life of a version of the MacOS (ignoring the 6.0 debacle). This is a result of the level of commitment to quality. Would you bet your product/company on MacApp without the source? Probably not. What about the toolbox? Most people do.
• Documentation.
  Again, no contest. Nothing in MacApp comes close to Inside Macintosh and the tech notes.
• Debugging/Tools
  Debugging is probably easier with MacApp because of the source availability and the debug mode. The toolbox could really use a debug mode like MacApp's (I hear that the next version of Discipline will be much better). If you don't have the source for a framework you'd better get a really good debug mode. Sourcebug is a good first version, but would benefit from the maturity of SADE. ViewEdit and the first few years of ResEdit are probably comparable. MacBrowse is nice.
• Design.
  Everybody has probably copied a method in MacApp and changed a couple lines. I regard this to be a failure in the design of a framework. For example, I do it much less in MacApp 3 than I did in version 2. It's much more difficult to design a good framework API than one for a procedural interface like the toolbox. Therefore you would expect a much larger investment from the developer. (Of course, the API is the part of the design that will always be available as source.)

This is in no way meant as a dig at MacApp. It has been steadily improving with each new revision. I'm sure that all of the people working on it are as committed to quality, etc. as anybody. The point is simply to illustrate the level of commitment from Apple. How much of the billions in R&D dollars in the last few years has gone into MacApp vs.. the toolbox? MacApp is supposed to be the recommended development environment for the Mac. Yet there seems to be no investment in documentation comparable to Inside Macintosh, and no investment in QA comparable to System 7. Apple seems to be willing to make a greater commitment to Pink than MacApp.

The question I have about Bedrock is not whether there will be source or not, but rather, how much of a commitment are Apple and Symantec willing to make to it.

Regards,
Nick Nallick

Sub: Bedrock as a standard

Fellow Bedrock Thumpers,

It sure is amazing to watch the MacApp discussion flare up and my phone bill go up at the same time. Let me return the favor by dishing out some of my own irrelevant opinions.

We should not be discussing whether Bedrock should ship with or without source code. We need to focus on what Bedrock really is. Is Bedrock a product or a standard?

Bedrock, as a product, is a gamble. A bad implementation, whether it ships with source code or not, will curse us all for the next five years. Despite all the efforts that went into MacApp, it is leaky, fat, and rigid - sort of like a stuffed elephant with stool problem.

Bedrock, as a standard, is the way to go. Apple should take charge of creating the standard and providing OS supports like dynamic linking. Symantec and other application framework vendors should provide Bedrock components.

Don Park

Sub: Re: Bedrock as a standard

I agree, Its weird I have been gone for a week, came back to MacApp3Tech and expected to find some real meat discussing the pros, cons, the problems with a cross platform tool and all there is a source code debate.

What features of my MA 3.0 app will not port to Bedrock?

• Cohandlers?
• Cool popups?
• View files?
• What classes are history?

What features my be separately maintained?

• View.rsrc files?
• others?

cheers,
Gary Campbell

Sub: Re: Sources or no Sources...

I could not have shipped a MacApp product WITHOUT the source CODE.

Why not,

1. Documentation

   Documentation for MA 2 was bad, you and everyone else are aware of why, split development/manual development.

2. Bugs

   Basically I ship MA apps with MY PATCHES to the MA SOURCE to make it reliable on my App to my customers.

3. Development

   Many many times, the only was I could figure out why I was getting bombed was by debugging into the MA source.

   Silly things like mis-spelling the 'fIdentifier' of an field or a Class name result in terrible failures.

   Maybe MA should be very helpful in these situations even if you are compiling with '-debug'. I never do any more.

cheers
Gary Campbell

Sub: Bedrock-Let's Get Real

Yes, let's get real!

Apple/Symantec's going to ship Bedrock in the first half of 1993 and we're not going to need source! Not!

Let's ignore the source code issue for the rest of this discussion and just talk about the likelihood that ANY group could deliver what everyone thinks they're going to need in that time frame.

Let's put on our project management hat for a moment and pretend we are the ones who are going to have to ship this product. We'll work backwards.

Ship Date: June 31, 1993.
April 1, 1993: Package Goes Golden Master

The product is going to have to be ready to package three months before FCS (First Customer Ship). Because it takes three months to get advertising space in most major magazines, there's still going to be bugs to fix, the documentation has to be printed, example programs have to be written, CD's have to be cut, etc. That's reality, right?

January 1, 1993: Product Goes Beta

There's no substitute for putting a development product into the hands of real, live, interested developers. Even though a three month beta is not really realistic either, we'll give it a shot.

Now let's go to the other end of the schedule: design and implementation.

July 1, 1992: Product Design

Is three months enough time to work out the design of Bedrock? Probably not (after all we did JUST barely close the deal with Symantec) but we'll tell management it is (because they might take the project out-of-house if we don't). We've got to take the existing frameworks (MacApp, and some other unspecified framework which none of us has ever heard of before and if it was soooo good wouldn't someone have hear about it?) and meld them into some reasonably designed, easy-to-implement, superior framework which solves all the problems inherent in the currently 'superior' frameworks.

September 1, 1992: Implementation

Though some implementation has already taken place and though we are building on existing frameworks there's still going to be a lot of coding to perform. Coding to correct some major flaws in the contributed framework MacApp (such as view's being grossly heavy weight-views being the major contribution to the effort) and coding to incorporate Macintosh/Windows concepts into a framework which I assume came out of the Unix world. Three months? Well it'll be too late for management to do anything about schedule slips.

Plus we've got to do the absolute best job of documenting the product so that developers can learn and design and code, provide tools for debugging, view construction and prototyping, and incorporating Quicktime, Quickdraw GX, etc.

Does anyone out there really think it will happen by June 31st, next year? I don't.

But I'll take whatever they give me. Because it will still be lightyears beyond anything else out there. Personally, I'd really like to see the class structure right away. That would be pretty enlightening.

Gotta go but please don't think I'm flaming, mad, or otherwise deranged. I just think we all need to be realistic about what can be done in a year.

Mike Rossetti

Sub: Re: Bedrock-Let's Get Real

Just got back from lunch where this very topic was discussed. The consensus was that Bedrock is either effectively complete NOW and all that remains is incorporating politically motivated "enhancements" (i.e. how much can we afford to alienate our MacApp developers, internal and external) *OR* the one year time frame is pure smoke. (We also discussed what might happen to the PC & Mac teams currently working on parallel projects. Unfortunately, we concluded that management will decide the Mac is a secondary machine, order development only on the PC, and then bring in a couple of contractors to build the Mac specific parts of the application after PC development is complete. Sorry, but that's the reality in a world that's 85% PC.)

In defense of the 1 year time frame:

There are some hints in the white paper and Q&A that Bedrock might really be almost done. It is described as being used internally at Symantec and that it is in the hands of some corporate developers and ISV's already. In addition the Q&A states that Symantec will be signing up "Early Developers" this fall.

On the other hand:

There's nothing I can add to your comments...

Your dose of realism should be appreciated by all. Sometimes we get so wrapped up in our own reality that we forget about that other reality.

Bill Colsher
SKAMP Computer Services
A'Link: SKAMP or the company shown above

Sub: Bedrock is in use already!

It's important for folks to understand that, as far as I know, Bedrock has already been used as the basis for several cross-platform Symantec products. I am certain that Symantec was telling people that it was "shrink-wrapped" and was trying out opinions on source-code issues, etc. in the early part of this year. And after all, Bedrock took as a starting point the TCL class design, which I'm told is pretty good. That is certainly the first place to look for hints about the future shape of Bedrock.

So Apple and Symantec are not starting from a stand-still, by any means. We may not see a "Think C++" right away, but the high standards of Symantec's tools (Think Browser, Documentation, support, etc.) will be there with Bedrock. I can see that Apple's contribution, beyond MacApp, is also the Unix-like MPW environment where Zortech's C++ actually does run. After all, MPW is much closer to DOS and UNIX than Think C is, right now.

The big question in my mind, as others have stated, is how much of MacApp's architecture will be translatable, and what the underlying "X-platform Toolbox" looks like - that is where the work will be for existing MacApp apps, right? I'm just now moving an app from MA 2.0 to 3.0 - sigh...

John Major
BBN Software Products

Sub: Re: Bedrock is in use already!

Indeed President of Symantec Gordon Eubanks said at the annoucement that Symantec has already used portions of Bedrock for both their TimeLine and Q & A Windows products. I believe Q & A is to be released soon for the Mac. Haven't heard anything in relation to TimeLine on the Mac.

-Ken Addison
FutureSoft System Designs

Sub: Bedrock Discussion

Hmmm...a 35 message thread about Bedrock over in Symantec's forum on CompuServe, and not one mention of the words "source code". There's even a little substance. That's more like it.

And...TCL users are just as used to source code as MacApp users are.

-John

Sub: Questions about Bedrock

I going to ask some questions straight out that I think most of us would like to know the answers to:
1. Other than a possible release of MacApp 3.0.1, is MacApp 3.0 now dead as far as further class enhancements (like QuickTime support, and some of the other requested features)?
2. Will we have to wait for Bedrock to get these much needed features? Or will there still be a MacApp 3.1?
3. Was this (Bedrock MacApp replacement) actually planned and well thought out? Or is it a knee-jerk reaction to developer's wish-lists here, at the MADA conference, and WWDC?
4. Did we bring this on ourselves (as in "Be careful what you ask for. You might get it.")?
5. No one has mentioned PowerPC. Is that to be transparently included?
6. How mainstream is Bedrock going to be in the entire Macintosh scheme of things? (Like concurrent class releases to support new system extensions? Or class releases to support what are now becomming "old" system extensions?)
7. How about DLLs (Dynamic Link Libraries)?
8. In spite of an announced doubling of support for developer tools, are the resources of the MacApp (Bedrock?) team going to be adequate for this very ambitious project? (I have my doubts. The MacApp teams obviously has some very bright people, but they deserve to be let out of their cage occasionally. If Apple computer really wants to take on Microsoft in both arenas plus PowerPC, I suspect they're going to have to double it at least a couple of more times.)
9. Whereas hardware development cycles are now getting compressed intomonths instead of years, the software development cycle and feature cycle are still very long. System Extensions -> Framework -> Program Code -> Product.Is there any chance of publishing at least projected schedules andclass/feature lists?
10. Is there any point (for the present) in developers continuing toexpress wish lists and architectural/performance suggestions? The earlier wecan get a look at Bedrock (in whatever stage of completion), the moreconstructive feedback can be provided. (Sure beats after-the-factwhy-the-h-did-you-do-it-that-way type of feedback.)
11. In general, I vote for published source code. However, I would notobject strenuously to (and might in fact welcome) compiled classes thatencapsulate and even bypass sets of toolbox calls for certain system extensionclasses, e.g., QuickTime, QuickDraw GX, CommToolBox. Any chance?
I'm sure I'll have a lot more questions, as will others. But it's a start.

G. Gordon Apple D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA

Sub: Platform Path

We were planning to start converting our application from Object Pascal to C++ and MacApp 2.0.1 to MacApp 3.0 this summer after the completion of our latest release cycle. This will not be a trivial task since, as far as we know, we are the largest Macintosh application in existence - more than 800,000 lines of code.

Well, we are going to continue with our plans to convert to C++, since it appears to be the only (non-dynamic) language option available.

However, the news of Bedrock and the "informal" announcement of the gutting of the MacApp team (reference Chris Knepper's note) has left us in a quandary (i.e., a polite way of saying confused and frustrated) over what platform path to follow.

To help clarify these platform options for us, I would appreciate your answers, opinions, or comments to the following:

• Why go to MacApp 3.0 when Bedrock is targeted to be out in less than one year?

  Yes, it has more features than MacApp 2.0.1, but, as a new release, it is still relatively immature. MacApp 2.0.1 is a known quantity (plus we have already incorporated the MABuild options -ModelFarCode, -ModelFarData, and -Proff). Also, the reviews about the MacApp 2 to MacApp 3 conversion process have been less than stellar.

• What are the plans for the maintenance and/or enhancement of MacApp 3.0? I am particularly disappointed that Apple has not even attempted any type of damage control after the announcement about the movement MacApp resources. More disheartening was the lack of a response when a (German?) developer posted a message stating that he was considering developing on an alternative *system* because of his experiences in reporting MacApp 3.0 bugs and asking for their resolution.
• If we decide to bypass MacApp 3.0 and wait for Bedrock, what is the incentive not to wait another several months for the subsequent release of Pink? I have heard much more favorable comments and projections for Pink than Bedrock.
• Since MacApp, Bedrock, and Pink are all Apple products (in one mutated form or another), which would you target to enhance an application of our size? I made this an open letter because I am also interested in what other people (i.e., the peanut gallery) are thinking about this subject.
I are looking forward to your reply and hope it *starts* to gives us a warm, fuzzy feeling that the "platform path" is not "the road to nowhere".

Sincerely,
Jack Boepple
Siemens Gammasonics

Sub: Re: Platform Path

To know if it's worth going to MacApp 3, an answer to this question would be helpful...

From the Bedrock QA:

One thing to remember about the transition is that although some code will not transfer, many programming skills developed for MacApp will apply to Bedrock. That would be true for any C++ class lib.

If you are already using the MacApp framework, the learning curve to adopt Bedrock will be low.

Well, that sounds better...I'd say part of a "low" learning curve was "Most classes and methods still work as before with the same arguments." Anyone from Apple want to agree with that, or compare the conversion effort to the MacApp 2->3 conversion?

And one more question: will Bedrock have a 'native' API that is different from it's MacApp semi-compatible API?