Family Tree Software Alternatives, Part 9: iFamily for Mac (Updated 20 May 2018)

Details about iFamily for Mac*

Application: iFamily for Mac
Current Version: 2.9.6
Supported OS: Mac
Mobile Apps: None
Price: $29.95 (demo available)
Publisher: KS Wilson & Associates
Website: http://www.ifamilyformac.com
GenSoftReviews: 4.98 stars out of 5 (15 ratings)

Version tested: iFamily for Mac 2.9.3 Demo version. The Demo has a time limit of 7 days and does not include GEDCOM export, which is a serious limitation.

Portions of text in all capital letters that are not acronyms are GEDCOM tags, with the rest of the plain text field name in lowercase. References to the GEDCOM standard are to version 5.5.1 unless stated otherwise.

Importing a GEDCOM file into iFamily is straightforward, but iFamily has instructions on their forum if you need help.

PROS

GEDCOM Import

+ GEDCOM import log: iFamily produces not just one, but three import logs. One log lists validation errors, a second lists unprocessed custom tags, and the third lists the first two categories along with all other unprocessed tags. It’s good that iFamily produces an import log, but it seems like the one called “UnprocessedGedRecs.txt” would be sufficient, since it includes everything from the other two logs.

+ FTM’s invalid use of the ALIA tag: FTM and a few other apps incorrectly use the ALIA tag in GEDCOMs for the “Also Known As” field. The ALIA tag should be used to provide a cross-reference to another person who may be the same. The closest thing the GEDCOM standard has to “Also Known As” is the Nickname field, whose tag is NICK. iFamily imported the ALIA tag into the Personal Comments field, which is good to preserve the data. Unfortunately, iFamily does not have a Nickname field.

+ Unrecognized data: For GEDCOM tags iFamily didn’t recognize, it generally imported them into Comment, Notes, or generic Events. This is good to preserve data, but it would be even better if iFamily recognized all GEDCOM 5.5 and 5.5.1 structures (see Cons).

+ Notes vs. Comments: In addition to Personal Notes, iFamily has a Personal Comments field. The distinction is that Notes are for information you believe to be true, while Comments are for information you haven’t verified yet or that may be sensitive. Comments are similar to Research Notes in FTM. Notes are exported to GEDCOM using the NOTE tag, but Comments are exported using the custom tag _CMTS. So any data that are imported into Comments should be moved elsewhere if you want to share them with others, because other apps are likely to ignore them.

+ Miscellaneous Events: Allows user-defined events to be added using a generic Event. Click the + at the bottom of the Events list and select Other Event. Change the Event name and add the date, place, notes, and sources as usual.

+ Event, picture, place, and source usage lists: iFamily has indexes for each of these categories; there’s a reference list for each item showing all the events or people they are associated with. You can also make global changes using these lists.

+ Source Transcription: iFamily has a split window where you can transcribe a source image. The image is on the left and the transcription is on the right. The window can be enlarged to fit your screen, and the image can be zoomed. I can’t tell how this text is exported, but hopefully it uses the Source Text tag (DATA.TEXT).

+ Display of Event Types & Reference Numbers: I like how iFamily displays most Event Types, because these correspond to their GEDCOM tags. However, the distinction between “Event Type” and “Event Name” is a little confusing and problematic (see Cons below). The Event Name is simply the clear text for the Event Type. Also, I like how iFamily displays individual, family, and source reference numbers because they correspond to those from my GEDCOM file, enabling me to easily compare them.

+ User interface: The iFamily interface is easy to use, and you can even change the colors and fonts if you don’t like the default green. Each window and tab has lots of little icons that aren’t necessarily intuitive, but if you hover the cursor over each one, a hint pops up showing what it’s for.

CONS

GEDCOM Import

— Is iFamily Actively Developed? After loading a GEDCOM file, I was presented with some information about my file and how long iFamily took to load it. When iFamily first came out in about 2006 (the first version was called iFamily for Tiger), computers were slower and importing a large GEDCOM could take a long time. But I think that’s much less of a concern now. The fact that the GEDCOM file load window mentions the iMac G5 PPC makes me wonder how often iFamily is updated (Fig 1). Even the Help file is labelled “iFamily for Leopard,” which it hasn’t been called for several years.

— Failed to recognize valid GEDCOM 5.5 tags ADDRess and PHONe. However, iFamily imported them to the corresponding event Note. Since iFamily only supports GEDCOM 5.5, it also failed to recognize the 5.5.1 tags EMAIL and WWW but did not import them to the event Note. Oddly, it pointed out that FACT was not a 5.5 tag but imported it anyway into the Comments. It also pointed out that the tag WAC, used by PAF and other apps for LDS Initiatory, was not a 5.5 tag but imported it as a generic event.

— Secondary Names: These are name structures that occur after the first name structure in an individual’s record in a GEDCOM file. iFamily imported secondary names to Personal Comments, which is less than ideal. In fact, there’s no other way to add additional names in iFamily except for the Personal Notes. There are also no fields for Name Prefix or Nickname, which are standard GEDCOM fields; they are imported into Personal Comments. These are rather serious omissions.

— Date Ranges: My GEDCOM contained the valid date range “BET 1870 AND 1871”; however, iFamily converted it to “Abt 1870” and moved the date range to the Event Note. This is unacceptable. A mature genealogy app like iFamily should be able to read and write all standard GEDCOM date formats.

— LDS Sealed to Parents: Failed to recognize the required FAMC tag indicating which family a child was sealed to and imported it into the event Note.

— Adoptive parents’ relationships: failed to recognize the GEDCOM tag PEDI indicating whether a family relationship was birth, adopted, foster, or sealing. Although iFamily has a Parent-Child Relationship Status field to indicate this, apparently it cannot read the PEDI tag since it complained about a child having two natural fathers, even though one of them was adoptive. iFamily changed the second father in the list to a stepfather. iFamily should be able to import and export the PEDI tag.

— Invalid event description: The only entry that a birth, death, or marriage event description (called a “descriptor” in the standard) may have is the letter “Y” to assert that the event occurred if and only if both the date and place are blank. Many genealogy apps violate this rule, including Family Tree Maker (FTM), which enabled me to include it in my test GEDCOM file. iFamily also violated this rule; it imported invalid event descriptions into the Event Name (Fig 2). The Event Name is the Event Type spelled out, such as “Birth” or “Death.” But where it should say “Birth,” it imported the invalid description instead, and there’s no way to change it. This is a serious shortcoming. Also notice in Fig 2 the statement, “An event must have a Date, a Type and a Name.” I agree an event must have a type, but a Name is required only for user-defined events like Arrival or Departure, and I strongly disagree that an event must have a date. If a date is unknown, it must be left blank (unless it can be estimated). Fortunately, iFamily doesn’t squawk if you leave the date blank. On its website, iFamily gives even worse advice; on the Tutorials page under Tips it states, “Enter ‘Y’ for a birthdate or deathdate if you want it to be searchable during consistency checks.” If a date is unknown, you should not enter “Y” in the date field (or the place field); you should enter it in the event description. But here’s the problem: iFamily doesn’t have a separate event description field; it has only the Event Name field, so if there’s both a description and a name (which is really a type), it can import only one or the other. That’s probably why it imported my invalid event description into the Event Name field. This shortcoming also leads to the next problem.

— Valid Event Descriptions: The GEDCOM 5.5.1 standard allows all events other than birth, death, and marriage, including generic events, to have descriptions, even when there is a date and/or place. For example, I have the following valid structure in my GEDCOM:

1 EVEN Mayor
2 TYPE Election
2 DATE 1868
2 PLAC Szepes County, Kingdom of Hungary

“Mayor” is the event description; GEDCOM 5.5.1 allows Event Descriptors on the EVEN tag, and my GEDCOM was labelled as version 5.5.1. This was a change in 5.5.1 (p. 48); previous versions did not allow descriptors on events. Unfortunately, iFamily doesn’t support 5.5.1 (see below under GEDCOM Export).

— Multimedia: iFamily cannot attach multimedia directly to events or source citations (what iFamily calls References); they must be attached to people or sources. Many users will find this to be a major shortcoming. Personally, I prefer to attach images to citations instead of sources, because there could be many images for one source, like a book, while citations have only one to a few images each.  At least iFamily appeared to import media attached to citations to the corresponding source, but it should allow media to be attached to all structures allowed by the GEDCOM standard, to include events and citations.

— Repositories: iFamily imported all repository information, to include name, address, phone number, email address, and item call number into a plain text field, so I can only imagine that the information would be exported to either a note or a custom field. Users who keep repository information might find this unacceptable.

— Source citations: iFamily calls source citations “references.” Both text from sources citations and citation notes are imported into the same reference note field. Of course, when the tree is exported to GEDCOM, the notes will be a jumble of notes and text from source.  iFamily should have separate fields for reference notes and text from source; this is the best practice followed by top-notch genealogy programs.

— GEDCOM 5.5.1: As noted above, the iFamily Demo does not include GEDCOM export. The iFamily website states, “As GEDCOM export is disabled in our demo, hold it’s performance to the same standard as our GEDCOM import process.” Fortunately, iFamily uses GEDCOM tags for its Event Types, so I could at least surmise what tags it would use to export a GEDCOM. iFamily expects GEDCOMs to be formatted according to GEDCOM 5.5 for import, so it undoubtedly exports them as 5.5. Modern genealogy apps should be able to import and export version 5.5.1, which is the latest standard (discounting version 5.6, which was similar to 5.5.1 but also include an XML structure that was never widely adopted). GEDCOM 5.5 allowed only the ANSEL, US ASCII, and UTF-16 character sets. GEDCOM 5.5.1 added the UTF-8 character set, which is now the most widely used character set on the World Wide Web (Wikipedia, citing several sources). GEDCOM 5.5.1 also added tags for fax numbers, email and web page addresses, and latitudinal and longitudinal coordinates. Without these tags, apps must use custom tags, like _LATI and _LONG in iFamily, which may be ignored by other apps. A final improvement of GEDCOM 5.5.1 is how it structured multimedia records. GEDCOM 5.5 had two ways of including multimedia: an embedded form using a binary object (called a blob) and a linked form including the full path and name of the multimedia file; notably, the linked form could not use cross-references, meaning every time a multimedia object was referenced, the complete file information, including title and format, had to be repeated. As far as I know, only two apps can currently embed binary objects in GEDCOMs, Family Historian and Ancestral Quest; Ancestral Quest cannot read Family Historian blobs, so there is a problem with compatibility. In any event, GEDCOM 5.5.1 eliminated the embedded form, leaving only the linked form. It also changed the structure of multimedia records to allow cross-references. So apps that can’t read or write 5.5.1, to include iFamily, are missing out on these improvements and failing to import data such as media titles and dates. I was surprised iFamily imported my media links at all, since my GEDCOM used cross-references, so clearly iFamily at least partly supports 5.5.1. Why not go all the way?

Other

• The Help file seems a bit thin and incomplete to me; it’s only eight pages long, including the table of contents, and like many things associated with this product, it’s out of date. It’s called the “iFamily for Leopard User Guide V2.522” dated 2011. The app has been called iFamily for Mac since at least 2014 and is now up to version 2.9.6. The User Guide is mostly an overview of the interface. There are no detailed instructions on how to do things. For example, I had a little trouble figuring out how to add a family event like a marriage; there’s nothing in the User’s Guide nor the website tutorials. Most of the tutorials are brief, and they don’t cover many topics.

• 

  The website is out of date and incomplete. Fig 3 is an example of a web page where placeholders from a web design template have been left in instead of hiding or removing them. This doesn’t strike me as very professional.

GEDCOM Crosswalk

I added the iFamily fields to the GEDCOM Crosswalk at Family Tree Maker to GEDCOM to Other Apps Crosswalk. This table shows at a glance how the major genealogy apps name their fields within the app and how they are exported to GEDCOM. The color coding indicates areas of concern: fields in red are not imported and/or exported correctly, while fields in yellow use custom tags that may not be recognized by other apps or websites.

First Impressions

iFamily has a nice, easy-to-use interface and several other positive features. This review focused on GEDCOM handling, because the ability to import and export correctly is one of the most important criteria for an app; GEDCOM is usually how family trees are exchanged between people using different apps. iFamily does a fairly decent job handling GEDCOM 5.5, compared to other apps. It’s unfortunate that iFamily doesn’t fully support GEDCOM 5.5.1, because it consequently can’t read modern tags for email and web addresses or fax numbers. It also failed to read valid event descriptions, a major shortcoming. But to me, the most serious shortcomings are the inability to attach media to citations and the combination of source text with citation notes. iFamily has had over 10 years to mature as an app, but I’d say it still has a ways to go.

GEDCOM 5.5.1 Test: iFamily fails the GEDCOM 5.5.1 Test. It incorrectly labels files exported using UTF-8 encoding as version 5.5; UFT-8 wasn’t allowed in 5.5.

Updates:

30 Apr 2016: Added a statement about the GEDCOM 5.5.1 Test.

20 May 2018: Made minor updates.

---

The Family Tree Software Alternatives Series

Part 1: How to Scrub Your Data
Part 2: How to Get Your Tree out of FTM
Part 3: RootsMagic 7
Part 4: Reunion 11
Part 5: MacFamilyTree 8
Part 6: Family Tree Builder 8
Part 7: Heredis 2015
Part 8: Gramps 5
Part 9: iFamily for Mac
Part 10: GEDitCOM II
Part 11: Legacy Family Tree 8
Part 12: Ancestral Quest 14
Part 13: Family Historian 6
Part 14: Should You Stick with Family Tree Maker?
Part 15: Brother’s Keeper 7
Part 16: RootsMagic 8
How Well Does Ancestry.com Handle GEDCOM?
Family Tree Maker to GEDCOM to Other Apps Crosswalk
The Perils of Following the GEDCOM Standard
Why All Genealogy Apps Should Support GEDCOM 5.5.1

*Information current as of the date of this post