TweetFollow Us on Twitter

WebObjects 4 Everyone

Volume Number: 16 (2000)
Issue Number: 5
Column Tag: Programming

WebObjects and EOF For Everyone!

By Patrick Taylor and Sam Krishna

Everyone, this is WebObjects and EOF. WebObjects and EOF, this is Everyone

When done well, programming provides an answer for a problem. At its worst, programming obscures the question. The first part of that statement isn't very controversial, few of us practice programming just for its pure aesthetic joy. We program for a reason and when we do it well, we achieve our purpose. The difficulty that the software industry find itself in is that normal practice more often resembles the worst case rather than the best. Applications are fat, slow, complicated and become impossible to maintain.

The tool you use won't prevent problems, after all, you can write just as bad a program in Java as in Visual Basic or PERL, but the development environment used can lead you in certain directions. WebObjects and Enterprise Objects Framework (EOF) have inherited from earlier NeXT-era tools a certain "cultural" approach to development that set them apart from practically all development software available today. While they may look similar to the dozens of other tools avalable for web applications development and serving, WebObjects and EOF do things differently. And it is these core differences that make them a good choice.

The biggest problem facing the developer unfamiliar with WebObjects or EOF (or any of the new generation Apple development tools) is that "cultural" divide. Many classic Mac OS programmers have been using object-oriented tools of one sort or another for well over 10 years starting perhaps with Object Pascal and ending with C++ or Java, however there is a strong sense that the object-oriented approaches we used were "bolted on." While our tools have been getting more object-oriented, the target platform (whether it is the MacOS, Windows or a web application server) is still as procedural today as it was in the 1980s.

In contrast, years before many of us had even heard the term, NeXT made object-orientation an essential aspect of their tools and platforms. Bear in mind, that this object-orientation is not of the timid C++ variety but the older and more radical SmallTalk variety of OOPLs (object-oriented programming languages). EOF and WebObjects bring this radicalism out of the academic closet and into the very practical world of databases and the Web.

The Back Story (A New Hope)

One of the difficulties in explaining why WebObjects and EOF are such powerful tools and technologies is that there isn't much of a common history. The back story of NeXT is partly known but like the history of the Macintosh, it is so intertwined with the story of Steve Jobs, that it is difficult to give the technology its due.

Apple hasn't been much help here. Many people in the industry refer to the way Apple sells WebObjects and EOF as "stealth marketing." Whether WebObjects and EOF are the best kept secrets of the web application market because Apple doesn't know how to sell to the enterprise or they are waiting until MacOS X arrives in its full "Aqua"-fied glory is the subject for an editorial not a technical introduction. There is a great deal to admire about these products and they could make a big difference to you as a developer, but the first step in demystifying is to tell the back story.

The Model-View-Controller software pattern

Model-View-Controller (or MVC) has its roots in SmallTalk, according to the famous Design Patterns book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. MVC consists of a triad of classes which are structured to decouple the behavior of the application from its user interface. In MVC, often the most reusable parts are the Model classes and the View classes while the Controller classes are rately reused.

An example would probably be the most useful here to illustrate what happens. Since Apple hasn't managed to significantly update the Calculator in the classic MacOS, you might want to develop a half-decent calculator. In this program, there would be a CalculatorModel class which has the code used to actually perform and return results of the computation; a CalculatorController class which is used to broker between the Calculator UI and the CalculatorModel class; and a CalculatorController class which is used to broker between the Calculator UI and the CalculatorModel class - it passes input from various digit and operations buttons and a text field to the CalculatorModel class to perform computation. The View part of the Calculator is actually a set of classes used to represent digits 0-9, the symbols for math operations (addition, subtraction, multiplication, and division), and a text field which actually can receive direct keyboard input as well as display computational results.

Before MVC, many programmers would simply cram all of this into a monolithic code mess: interface, computational engine and all. The computation code for 'addition' be inside of the '+' (plus) code widget! Perhaps this doesn't seem like such a terrible thing, but by separating the Model and the View, we could use WebObjects to build a new view based on either HTML or a Java client applet which used the exact same computation engine. Or we could build an interface designed just for Windows. Or convert the interface to compute using Roman numerals. While this might not seem like such a big deal for a calculator, it makes far more sense for hundreds of higher-end applications.


The EOF 2 team realized they needed to have broad functional separation as well as leverage off of the work of the engineering team behind AppKit, the desktop UI framework for Openstep aka Yellow Box aka Cocoa. In general, database functionality breaks down in three places: the interface or display of the data fetched; access, the actual retrieval and manipulation of the data at the database level; and control, the layer which brokers between interface and access. EOF2 provided a database-specific variation on MVC, and it worked spectacularly well.

The Access layer is responsible for actually generating the SQL necessary to create a "state reflection" of the actual state of the EOs (Enterprise Objects) in memory at the time the EOF equivalent of a commit is called. There are two distinct layers to the Access layer: the EOAdaptor layer and the EODatabase layer. At the lowest level, the EOAdaptor layer is responsible for the SQL generation. The EODatabase layer is responsible for taking the rows fetched through the EOAdaptor layer and packaging them into EOs and registering this with the Control layer. What's incredibly cool about the Access layer is that all your SQL is generated for you at runtime-you don't ever have to write SQL again if you're just doing generic SELECTs, INSERTs, UPDATEs, and DELETEs.

The Control layer is responsible for managing the EOs in memory and notifying both the Interface and Access layers to update their information whenever EOs change in memory or when a commit is requested by the user. Without getting into too much detail, the Control layer is responsible for managing the state information of the EOs as well as controlling the other layers.

There are actually two different versions of the Interface layer: the WebObjects framework and the EOInterface framework. EOInterface is used for desktop applications and maps various attributes of EOs to desktop widgets; while the WebObjects UI framework does the same, but from a web perspective.

Unless you have some of that history, you'll probably always wonder why the original developers did what they did. Or, alternately, you could resort to the ever-popular "it just works" explanation. Since neither of these options puts any food on our table, this series will attempt to explain WebObjects and EOF, not just in a technical way, but also in a historical sense. There is much more to know there than the fact that WebObjects has the cool name and EOF the dorky one.

So if you want to understand NeXT technologies, you should at least know a little bit about Objective C ...

A brief story of Objective C or "When you use C++, your objects can't hear you scream"

Computer languages can inspire remarkable loyalty. Regardless what flaws might exist, there is rarely a language that doesn't possess at least a small cult of dedicated followers. Flame wars between language advocates are so ever-present that it has become commonplace for language agnostics to argue that all languages are equally useful. This is a nice sentiment, but all languages have different strengths and weaknesses. As a friend of mine used to say, "Pizza is nice, pizza is tasty, but you can't eat pizza every night." Objective C is such a language, full of advantages and flaws, some perceived, some real. And it was just those properties of Objective C that made WebObjects and EOF possible.

Languages are created as an answer to an immediate problem. In the case of Objective C, the problem was one described back in 1968 as the "software crisis." Fred Brooks wrote about this problem in his seminal work "The Mythical Man-Month" and in his famous article "No Silver Bullet: Essence and Accidents of Software Engineering" In a nutshell, the software crisis is caused by the difficulty to scale software development. An insufficient number of people are available to develop the increasingly more complex applications the market demands. The paradox is that adding more workers to a project is not a solution; in fact, this would most likely aggravate the situation due to difficulties in managing the increased communication complexity and the new workers' varying levels of technical ability. According to Brooks, the problem is not one that will ever improve dramatically because the very nature of software development will impede this change. And despite the huge libraries of how-tos and programming methodology books, Brooks' thesis seems to be holding true.

Brad Cox didn't believe this had to be so. In his Byte article "What if there is a Silver Bullet: And the Competition Gets There First?", Cox argued that the problem isn't structural to computer programming itself, but had more to do with the way the industry carried out development. Taking an artisan-like approach to programming, developers were creating unique implementations of software each and every time. Brad Cox proposed the idea that software development needed to go through its own "Industrial Revolution."

While code-reuse gets a lot of lip service today, it is still rare that significant amounts of code get reused. And-this is the critical point-even when we do practice reuse, we do it as an add-on. To overcome the software crisis, the whole process of coding must change to make it simpler to practice reuse. "Re-user-friendly," if you will.

Many people complain about a problem, Brad Cox did something about it. He created Objective C, a computer language that added a small set of object-oriented extensions to the ever-popular C language. Among its other features, Objective C featured a dynamic runtime that allowed compiled objects to communicate with other objects without knowing the exact implementation of the target object. The reason for the dynamic runtime was that Cox foresaw a day when programming involved groups of interchangeable "software widgets."

Cox didn't create Objective C from scratch, he borrowed the syntax and philosophy from SmallTalk, the grand-daddy of object-oriented programming languages. SmallTalk was an interpreted language environment whose remarkable flexibility was used to create the first graphical interfaces emerging from Xerox PARC. Some of the finest minds in computing are associated with SmallTalk, including Alan Kay, a Macintosh legend in his own right, and Kent Beck, author of several classic books on programming.

While far more advanced than any other programming language of its day, SmallTalk's problem (other than its sheer alieness when compared to the procedural languages of the day) was that, being interpreted and message-passing, there were significant performance problems. The tradeoff of performance for flexibility and development speed were minor ones for the academics and researchers who used SmallTalk to create the early prototypes of our present day interfaces and applications. Commercially SmallTalk was much harder to sell, not that the hardcore fans didn't try.

Brad Cox however took a middle road and hybridized SmallTalk (easy to program and reuse) with C (fast and compiled) to create Objective C. Almost two decades later, it is easy to forget that Cox was working in a world where microcomputers had 8- or 16-bit processors that topped out at about 8 MHz. Many programmers still swore by assembler due to the scarcity of resources, not the least of which was less memory than you'll find included standard on an L-2 cache on a modern processor.So while far from perfect, Objective C was probably the best compromise between his goals and the reality of the computer industry at the time.

Steve Jobs exits, stage left. Then returns triumphantly.

Few figures have dominated the computer industry like Steve Jobs, and none have done so in quite the same way. After his much-publicized break from Apple, Steve Jobs was looking for another opportunity to change the world. This time, however, he would do it right.

What he ended up doing was collecting a rag-tag group of geniuses to build a brand-new operating system. There was little about NeXT's new product that wasn't leading edge. Often the trade press have focused on the Unix internals, however, what distinguished NeXT's OS from the competition was the object-oriented frameworks hosted above the BSD/Mach kernel. Inspired by the same Xerox PARC visit that fueled Jobs' excitement for graphical interfaces, object-orientation became the core competency of NeXT. Steve Jobs became the object's most charismatic advocate.

"When I went to Xerox PARC in 1979, I saw a very rudimentary graphical user interface. It wasn't complete. It wasn't quite right. But within 10 minutes, it was obvious that every computer in the world would work this way someday .... Once you understand objects, it's clear that all software will eventually be written using objects .... It's so compelling. It's so obvious. It's so much better that it's just going to happen."

Quoted from "Steve Jobs: The Next Insanely Great Thing" Wired 4.02 Feb. 1996

When NeXT's software engineers were searching for a language with which to write their object-oriented frameworks, they didn't have the wealth of options available today. OOP was far from a mainstream choice in the mid-'80s even if Byte magazine and other "voices in the wilderness" kept announcing that this "future" was just around the corner. However, while everyone else was waiting, NeXT's engineers were creating just such a workstation-class computer. A major considerating was performance, but since they were creating a brand-new platform they also wanted to dramatically ease development. Almost twenty years after the software crisis had first been articulated, little had occurred to improve the development situation. In fact, fatware, or sloppy design which resulted in inefficient application programming, was increasingly becoming a problem especially with the introduction of graphical interfaces and in the later '80s the features-race. NeXT attempted to use OOP as a practical way to fight the software crisis and reduce fatware.

Objective-C's qualities both simplified the creation of and pre-defined many of NEXTSTEP's features. The dynamic nature of its runtime along with its support of weak-typing allowed the OS to evolve dramatically without having to rewrite the entire codebase from scratch. The efforts that NeXT engineers were making on behalf of third-party developers paid off for NeXT itself.

Unlike Microsoft Foundation Classes or Metrowerks Powerplant, NeXT's frameworks weren't abstractions of procedural APIs. The development frameworks were the target APIs, in fact, in a very real sense, the NeXT frameworks were the only part of the OS that truly matter (which NeXT engineers proved when they ported the frameworks from Mach/BSD Unix to Solaris, HP-UX, and Windows NT).

Written in Objective C, these frameworks were collections of common interface elements and data types which could be easily added to your application. While not quite a collection of "software widgets" as Cox envisaged, Appkit and Foundation gave developers a head-start in creating new applications by eliminating most of the grunt work. By breaking up the application into Model-View-Controller segments, the NeXT approach (inspired by SmallTalk) allowed developers to split the interface from the logic underneath. This increased the reusability potential of objects since they weren't tied to particular interface elements. The principle was that you, the programmer, should only have to develop the parts of an application that make it unique, while as much of the remaining parts should be pre-fabbed or easily adapted to new uses.

NeXT had figured out how to create freeze-dried interfaces that generated no code. Literally, the objects that represents windows, buttons, and other views are put into suspended-animation, and then re-animated whenever a new instance of the application runs as a consequence of the dynamic runtime messaging. No new code generated means no new code to debug, drastically reducing the amount of time needed to bring an application to market.

The advantages of dynamism vs. static programming or "Why garbage collection is only important on garbage day"

Dynamic typing in Objective-C freed the EOF developers from worrying whether a particular object was going to work in a particular transaction. Due to dynamic typing, objects in Objective-C are purely orthogonal structures that do not need to be concerned with how they fit (or don't fit). You simply message them, not caring ahead of time whether that object can receive that message or not. The disadvantage to this approach is that sometimes you can message an object that does not (or can not) respond to the message, and the runtime will throw an exception bringing the app to a halt.

In static typing (or strong typing), the programmer defines ahead of time if something can respond to a message or not at compile time. In Java, you always have to downcast an object that is returned from a collection class which makes things less flexible. Since these objects are not orthogonal, you have to be concerned with how they fit (and how to message them). While useful for type-checking and message-checking purposes, it makes things much harder to manipulate and write truly reusable code-particularly if you're working with code that didn't originate with you.

Flexibility in typing hasn't been considered to be as significant a feature in a programming language as it should be. Many people rave about Java being one of the first mainstream languages to have garbage collection, which automates the process of memory management reducing the incidence of memory leaks and prematurely deallocated objects. This can save the programmer, especially the newcomer, a considerable amount of time. Unlike the benefits behind weak typing, garbage collection is of benefit only for each particular development project. Weak typing is far more usable because objects are allowed to be purely orthogonal structures and can be re-used in unexpected ways.

One of the key elements of reusability (in the NeXT/SmallTalk model) is that you shouldn't have to be concerned ahead of time about the usage of a particular class or object. With dynamic typing, you can store things in an NSArray (a particular collection class), without being concerned if it will actually go in or come out in the same form. In a statically typed context, you can still store things in the equivalent of an NSArray, but you will have to re-cast it back into its orginal form on the way back out. Also, you can forget about easily storing objects of different class types into an NSArray. It can still be done, but in order to message the object individually, you will have to remember its class type ahead of time.

As you can see, static typing encourages just the "artisan" approach that Brad Cox wanted to avoid when he created Objective C. The developer must omnisciently manage all the interactions between different parts of the program. As the application increases in complexity, the number of potential interactions explodes beyond what is reasonable for a single person to manage. The addition of more people complicates the situation because they must communicate the potential interactions to each other, increasing problems by misinformation.

By not requiring strong typing, Objective C allows wholesale replacement of objects so long as they are able to adequately respond to messages sent to them. Since the objects only need to know what messages they can respond to rather than knowing the properties of all the objects they communicate to, NeXT applications can scale better. This makes Objective C a bit "chatty" as OOP goes, but as you become more familiar with the NeXT Way of Things, you'll see that this is definitely a feature rather than a disadvantage.

There were very real and practical consequences to their design decisions for the developer. Andrew Stone, CEO of Stone Design, nestled in Albuquerque, New Mexico, has quietly developed a stable of products that would be impressive in a company ten times its size. "Doing things in a complex way is the wrong way to do things," said Stone, "[The NeXT approach allows the developer to] learn a subset of things rather than learning all of it."

As you can imagine NeXT's frameworks had several advantages over its competitors. And for several years, the biggest advantage was that NeXT's frameworks existed commercially while giants like IBM, Apple and Microsoft stumbled. And stumbled badly.

Bringing the NeXT religion to databases

As the 1980s gave way to the 1990s, NeXT's focus shifted to the enterprise. NeXT's frameworks were well suited to creating the client-server applications that were becoming so popular in Corporate America. When one talks about client-server, they are generally talking about working with databases and in the enterprise talking about databases means SQL. The Standardized Query Language (SQL) was intended to provide developers with a common way to interact with data assets, and yet even today, few relational database systems (RDBMS) support SQL in its entirety. Even this standardization is not much help since SQL programming tends to be a hairy exercise even for experienced developers.

How hard is it to write a database application the traditional way?

Well, the answer is: it depends. At some point, a few things have to be dealt with: SQL to fetch the data, SQL to update the data, SQL to insert the data, and SQL to delete the data (at the base level). And when a web application server is tossed into the mix, there's also the issue of importing the data from the SQL database to the web application to be manipulated programmatically and then back when it's time to commit the state of the program back into the database. This doesn't even include issues like stored procedures.

Other application servers often have innovative ways of letting you write the SQL yourself (whether it's in the web pages or in the code, or in some SQL template file). Often SQL coding is not much better than statically bound programming-the burden is on the developer on how to make the SQL work with the objects, or the objects work with the SQL, or in some mind-bendingly awful situations, both. Some application servers insulate you from things like SQL by tying the developer to one particular brand of database.

In most circumstances, EOF saves you from that by generating the SQL dynamically for any database that has an adaptor written for it. You didn't hear wrong, EOF generates SQL dynamically. No templates, no pseudo-SQL, no umbilical cord to a single database. EOF will build the required SQL commands to carryout what you've modelled and enabled programmatically. You don't ever have to write SQL again if you don't care to-unless you have some really high-performance requirement or an incredibly complex query that EOF can't do. If you're a masochist or just love SQL, you can write stored procedures or embed your SQL in the code, and have EOF execute it directly.

EOF is what makes WebObjects exciting, WebObjects is what makes EOF practical.

The roots of EOF extend almost 10 years back to an early object-oriented database framework called DBKit. This proto-EOF was NeXT's first attempt at mapping object-orientation concepts to RDBMS. This was not an academic exercise but an attempt to answer a non-trivial problem: How can we successfully apply the advantages of object-oriented programming to relational databases? NeXT had already shown that OOP could be a silver bullet for application development, but the answer to the OO-RDBMS problem was not immediately obvious.

DBKit was not a resounding success, it suffered several flaws which kept it from being a practical addition to the NeXT frameworks. It wasn't layered sufficiently, though it did begin the process of adding adaptors to databases. And unfortunately, it suffered the kiss of death from a lack of reference counting and countless memory leaks. However, DBKit was a pioneering attempt and it was important step towards the eventual solution. Wounded but not defeated, NeXT's software engineers returned to the problem once again and EOF 1.x was born. Certain key features like EOEditingContext were missing, so even EOF 1.x didn't provide all the answers.

EOF 2 saw the light in 1996, after WebObjects 1.0 shipped which was architected to take advantage of features from EOF 1.x. EOF2 was an apex in NeXT's framework history. Significantly, it laid the foundation for all versions of WebObjects since. After EOF2, the framework has been refined rather than rearchitected even in the age of Rhapsody and MacOS X. However, it had to die twice (in both DBKit and EOF 1.x forms) before it could come back to solve the fundamental problem of mapping OO-RDBMS development properly.

As it happened though, EOF 2 did not set the world on fire. Coming of age just as the World Wide Web was beginning to take off, the frameworks seemed to be answers to old questions. The client/server market began thinking outside the LAN to WANs and extranets, things that were exotic when EOF was being created. Its key market just wasn't as interested anymore.

The crucial step in going from apparent failure to promising success was in realizing how broad the question was that the EOF Team was answering. The true potential of both EOF and WebObjects was redeemed when the team members realized how powerful the two technologies could be working together. Rather than reinventing fragments of the functionality in EOF to solve what the engineers had thought were WebObjects' problems, they revolutionized the Web through a synergy of these two formerly independent technologies.

The rest of the articles in the series will specifically look at key elements of WebObjects and EOF. Layer, by layer, each article will reveal new and sometimes revolutionary features of this remarkable technology. In order of appearance, here are brief summaries of what we will cover.

The Request-Response Cycle

WebObjects provides an object-oriented abstraction of what occurs during an HTTP request-response cycle. Normally, a browser makes a request for a page from the server, the server responds by serving the requested page, if available, to the correct browser. WebObjects provides the developer with several vector hooks to intercept, augment or even completely override this standard behaviour from within the programming environment. By carrying this out from within WebObjects, the developer take advantage of a real application system behind a web server.

State Management

By virtue of its statelessness, HTTP makes the job of managing client-server interactions a major effort in any web application. WebObjects manages state at three independent levels: global, user and local; represented by three scope states: WOApplication (global), WOSession (user) and WOComponent (local). These allow the developer to vary state without having to write vast quantities of custom code or script unique behaviours. State management happens in the application code base allowing the developer to create unique behaviours for different apps. In fact, after using WebObjects for any amount of time, you'll begin to fall under the illusion that HTTP is state-oriented after all. Why everyone doesn't manage state like this may be the biggest mystery of all.


EOModelling is cornerstone of EOF, the way in which Entity-Relationship modeling gets done. Objects are modeled as EOEntities which have corresponding RDBMS tables. Columns in tables have corresponding EOAttributes which are the atomic units that comprise EOEntities. A relationship between two tables is represented by an EORelationship. And all of this is neatly packaged together in an EOModel. Again, once you understand EOModeling, you'll wonder why there's any other conceptual competitors.


EOKeyValueCoding is the universal protocol (or in the case of Java, interface) that allows EOF to have access to all ivars/attributes/accessors/methods in a standard, uniform way. Denoted primarily by two methods, takeValue:forKey (Java: takeValueForKey() ) and valueForKey: (Java - valueForKey() ), EOKeyValueCoding performs the runtime mapping of an individual table row to a corresponding enterprise object (EO) in the EOF runtime layer. This is key to the RDBMS to object mapping process that EOF uses. EOKeyValueCoding also allows the universal manipulation of these EOs without actually having to guess at what the accessors will be. EOKeyValueCoding allows all objects (not just EOs) to represent themselves as dictionary objects, which in turn further blur the strong typing/weak typing distinction.


The EOFaulting mechanism frees the EOF developer from the worry of explicitly fetching (or implicitly fetching) the entire relationship-driven object graph of a given EO. For example, if you fetched a SalesPerson EO, you wouldn't have to worry about also fetching the SalesPerson's Department, Manager, and Customer EOs as well (at least at fetch time). And if you wanted to know about those other relationships, all you have to do is ask the SalesPerson about its particular relationship, and EOFaulting performs a just-in-time fetch of the EOs for a given relationship.


The EOEditingContext is the capstone of the Enterprise Objects Framework. It also is arguably the most powerful class ever written in the history of object-oriented programming. Once it was developed it became central to the rearchitecting of EOF from version 1.x to 2.x. The EOEditingContext manages row insertion, row deletion, row updating, and row fetching. It also tracks the changes in both an undo/redo scope for all EOs registered with the EOEditingContext. Ultimately, it manages the transaction scope for a particular series of events all the way through its existence. It knows all and can do all.

In conclusion

Any cultural change involves a significant amount of effort. And it would be wrong to minimize the learning curve that WebObjects and EOF involve, this is not a "Learn WebObjects during your Lunch Break" article series. While, the new developer pays a bigger price at the start but each breakthrough made will pay off throughout the rest of the learning process. WebObjects and EOF are remarkable consistent so you will find remarkably few areas where the rules you internalize don't apply where you expect them.

NeXT and now Apple seem to follow a pattern of creating frameworks that are simple, but not simplistic, complex but not complicated. When you understand the philosophy, there is an opportunity to bring this elegance to your own software.

Apple Inc.
Microsoft Corpora
Google Inc.

MacTech Search:
Community Search:

Software Updates via MacUpdate

TinkerTool 5.3 - Expanded preference set...
TinkerTool is an application that gives you access to additional preference settings Apple has built into Mac OS X. This allows to activate hidden features in the operating system and in some of the... Read more
Audio Hijack Pro 2.11.0 - Record and enh...
Audio Hijack Pro drastically changes the way you use audio on your computer, giving you the freedom to listen to audio when you want and how you want. Record and enhance any audio with Audio Hijack... Read more
Intermission 1.1.1 - Pause and rewind li...
Intermission allows you to pause and rewind live audio from any application on your Mac. Intermission will buffer up to 3 hours of audio, allowing users to skip through any assortment of audio... Read more
Autopano Giga 3.6 - Stitch multiple imag...
Autopano Giga allows you to stitch 2, 20, or 2,000 images. Version 3.0 integrates impressive new features that will definitely make you adopt Autopano Pro or Autopano Giga: Choose between 9... Read more
Airfoil 4.8.7 - Send audio from any app...
Airfoil allows you to send any audio to AirPort Express units, Apple TVs, and even other Macs and PCs, all in sync! It's your audio - everywhere. With Airfoil you can take audio from any... Read more
Microsoft Remote Desktop 8.0.8 - Connect...
With Microsoft Remote Desktop, you can connect to a remote PC and your work resources from almost anywhere. Experience the power of Windows with RemoteFX in a Remote Desktop client designed to help... Read more
xACT 2.30 - Audio compression toolkit. (...
xACT stands for X Aaudio Compression Toolkit, an application that encodes and decodes FLAC, SHN, Monkey’s Audio, TTA, Wavpack, and Apple Lossless files. It also can encode these formats to MP3, AAC... Read more
Firefox 31.0 - Fast, safe Web browser. (...
Firefox for Mac offers a fast, safe Web browsing experience. Browse quickly, securely, and effortlessly. With its industry-leading features, Firefox is the choice of Web development professionals... Read more
Little Snitch 3.3.3 - Alerts you to outg...
Little Snitch gives you control over your private outgoing data. Track background activityAs soon as your computer connects to the Internet, applications often have permission to send any... Read more
Thunderbird 31.0 - Email client from Moz...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more

Latest Forum Discussions

See All

Jacob Jones and the Bigfoot Mystery : Ep...
Jacob Jones and the Bigfoot Mystery : Episode 2 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: Jacob Jones is back in Episode 2 of one of Apples 'Best of 2013' games and an App Store... | Read more »
New Trailer For Outcast Odyssey, A New K...
New Trailer For Outcast Odyssey, A New Kind of Card Battler Posted by Jennifer Allen on July 25th, 2014 [ permalink ] Out this Fall is a new kind of card battle game: Outcast Odyssey. | Read more »
Garfield: Survival of the Fattest Coming...
Garfield: Survival of the Fattest Coming to iOS this Fall Posted by Jennifer Allen on July 25th, 2014 [ permalink ] Who loves lasagna? Me. Also everyone’s favorite grumpy fat cat, Garfield. | Read more »
Happy Flock Review
Happy Flock Review By Andrew Fisher on July 25th, 2014 Our Rating: :: HERD IT ALL BEFOREUniversal App - Designed for iPhone and iPad Underneath the gloss of Happy Flock’s visuals is a game of very little substance. It’s cute, but... | Read more »
Square Register Updates Adds Offline Pay...
Square Register Updates Adds Offline Payments Posted by Ellis Spice on July 25th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Looking For Group – Hearthstone’s Curse...
For the first time since its release (which has thankfully been a much shorter window for iPad players than their PC counterparts), Blizzard’s wildly successful Hearthstone: Heroes of Warcraft CCG is sporting some brand new content: the single... | Read more »
Poptile Review
Poptile Review By Jennifer Allen on July 25th, 2014 Our Rating: :: SIMPLY FUNUniversal App - Designed for iPhone and iPad Simple yet a little bit glorious, Poptile is a satisfying entertaining puzzle game with oodles of the ‘one... | Read more »
Modern Combat 5: Blackout Review
Modern Combat 5: Blackout Review By Brittany Vincent on July 25th, 2014 Our Rating: :: LESS QQ, MORE PEW PEWUniversal App - Designed for iPhone and iPad The fifth entry into the blockbuster Modern Combat series is what mobile... | Read more »
Watch and Share Mobile Gameplay Videos W...
Watch and Share Mobile Gameplay Videos With Kamcord Posted by Jennifer Allen on July 25th, 2014 [ permalink ] iPhone App - Designed for the iPhone, compatible with the iPad | Read more »
THE KING OF FIGHTERS '98 1.0 Device: iOS Universal Category: Games Price: $3.99, Version: 1.0 (iTunes) Description: Series’ masterpiece “KOF ’98” finally joins the battle on iPhone! FEATURES:■ The best game balance in the “KOF”... | Read more »

Price Scanner via

iMacs on sale for $150 off MSRP, $250 off for...
Best Buy has iMacs on sale for up to $160 off MSRP for a limited time. Choose free home shipping or free instant local store pickup (if available). Prices are valid for online orders only, in-store... Read more
Mac minis on sale for $100 off MSRP, starting...
Best Buy has Mac minis on sale for $100 off MSRP. Choose free shipping or free instant local store pickup. Prices are for online orders only, in-store prices may vary: 2.5GHz Mac mini: $499.99 2.3GHz... Read more
Global Tablet Market Grows 11% in Q2/14 Notwi...
Worldwide tablet sales grew 11.0 percent year over year in the second quarter of 2014, with shipments reaching 49.3 million units according to preliminary data from the International Data Corporation... Read more
New iPhone 6 Models to Have Staggered Release...
Digitimes’ Cage Chao and Steve Shen report that according to unnamed sources in Apple’s upstream iPhone supply chain, the new 5.5-inch iPhone will be released several months later than the new 4.7-... Read more
New iOS App Helps People Feel Good About thei...
Mobile shoppers looking for big savings at their favorite stores can turn to the Goodshop app, a new iOS app with the latest coupons and deals at more than 5,000 online stores. In addition to being a... Read more
Save on 5th generation refurbished iPod touch...
The Apple Store has Apple Certified Refurbished 5th generation iPod touches available starting at $149. Apple’s one-year warranty is included with each model, and shipping is free. Many, but not all... Read more
What Should Apple’s Next MacBook Priority Be;...
Stabley Times’ Phil Moore says that after expanding its iMac lineup with a new low end model, Apple’s next Mac hardware decision will be how it wants to approach expanding its MacBook lineup as well... Read more
ArtRage For iPhone Painting App Free During C...
ArtRage for iPhone is currently being offered for free (regularly $1.99) during Comic-Con San Diego #SDCC, July 24-27, in celebration of the upcoming ArtRage 4.5 and other 64-bit versions of the... Read more
With The Apple/IBM Alliance, Is The iPad Now...
Almost since the iPad was rolled out in 2010, and especially after Apple made a 128 GB storage configuration available in 2012, there’s been debate over whether the iPad is a serious tool for... Read more
MacBook Airs on sale starting at $799, free s...
B&H Photo has the new 2014 MacBook Airs on sale for up to $100 off MSRP for a limited time. Shipping is free, and B&H charges NY sales tax only. They also include free copies of Parallels... Read more

Jobs Board

*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Sr. Project Manager for *Apple* Campus 2 -...
…the design and construction of one building or building components of the New Apple Campus located in Cupertino, CA. They will provide project management oversight for Read more
WW Sales Program Manager, *Apple* Online St...
**Job Summary** Imagine what you could do here. At Apple , great ideas have a way of becoming great products, services, and customer experiences very quickly. Bring Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.