Safe to say all are in little endian nowadays ?

For games, it's pretty safe. For embedded devices, micro-controllers, digital signal processors, network hardware, etc. it's not safe.

All the devices you will encounter are little endian.

A small percentage of servers, like AIX, are big endian. You will not encounter these in games, not even for server back-ends. Those are the "big iron" machines running Cobol in the back offices of old banks, or the ancient air traffic controller centers.

An small percentage of microcontrollers are big endian or mixed endian. You probably aren't writing games for an audio signal processor chip.

Every PC, laptop, desktop, server, phone, tablet, game console, or other interesting device for games is little endian.

Even back in the older days, the only time you needed to worry about it was when you were transferring data from one system to another system, such as moving data to/from a "big iron" machine and a terminal. Some data protocol specify "network byte ordering", which is big endian. Some data files also specify big endian, but that is rare these days.

At present and going forward it certainly seems the trend is little endian. But I feel compelled to point out that just one generation ago the consoles were both big endian architectures (X360 and PS3). I would be mildly surprised if it swung that way again, but those PowerPC platforms are still "in the wild", if only currently (semi-recently) supplanted.

Regardless, detecting/supporting either endianness is not terribly difficult so long as you can isolate it to whenever you're serializing bytes, be it networking or file I/O.

Nope. Never safe to say anything like that. It's like structural engineers saying "we don't need to take earthquakes into account because we haven't had earthquake in the last 50 years anyway."

Except earthquakes directly interfere with a bridge, while on the other hand, you have full control what external access exists, and which conditions it should obey to make it work.

You can also test/validate the system endianness at runtime like so (although "runtime" is sort of a misnomer in this case, as the compiler might very well optimize this down to simply the proper result):

eEndianness GetEndianness()
{
    eEndianness endianness = eUnknown;

    uint16_t test = 0xff00;

    uint8_t* pPtr = (uint8_t*)&test

    if ( ( 0x00 == pPtr[0] ) && ( 0xff == pPtr[1] ) )
    {
        endianness = eLittleEndian;
    }
    else if ( ( 0xff == pPtr[0] ) && ( 0x00 == pPtr[1] ) )
    {
        endianness = eBigEndian;
    }

    Assert( eUnknown != endianness );

    return endianness;
}

You can also test/validate the system endianness at runtime like so...

I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.

As to the question of frequency, most ARM chips can run in either endian. Power chips (the newer variants of PowerPC) are also bi-endian. You'll probably never run into such a chip in games development, but if you are writing generalised software, there's still a decent chance.

Just put an ifdef or static assertion in any bit of the code affected by endianness (which should be like, 0% of your structures) and then fix it when you port to one of those platforms later.

I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.

Just put an ifdef or static assertion in any bit of the code affected by endianness (which should be like, 0% of your structures) and then fix it when you port to one of those platforms later.

Yes, I was not quite clear enough on the intent. I didn't mean to imply you would need to do this "live" all the time. Rather, you can use it to validate that your assumption about the endianness of the system is valid. To Hodgman's point, an assertion or static assertion at the right place to indicate if there's a mismatch.

You'd only typically worry about this when you are transferring data from one system to another, and that check should still apply even today. But, it's not a compile-time check "is my architecture big or little endian?", more like a runtime-check "is this byte array using big or little endian?" I typically just dictate that on the format of the file, that whoever is de/serializing it should use that endian regardless of the system.

If you are saving game data from and for a particular system only, then you should use whichever the architecture uses.

Yes, I do the same, I use a value 1 or 0 for little / big endian and then I have simple inline function which check the endian source to convert using the define of the actual compilation endian.
So, basically it's more an issue to check the good endian based on platform because then all others place uses the #ifdef to know the actual endian.

If you are saving game data from and for a particular system only, then you should use whichever the architecture uses.

This. You don't ship the same assets on every platform. You burn big-endian encoded files on your Xbox360 DVDs, and little endian encoded files on your X86 Windows DVD.

The main groundwork here is making sure that your engine is designed to compile your data once for each platform.