As web apps increase in popularity in the mobile space, designs traditionally built for native iOS or Android apps have started to find their way into the hands of web developers. Web development and native app development can pose some very different challenges. If you've designed a lot of native apps, knowledge of the process a web developer goes through can really help your designs hit the ground running.
Native apps vs web apps
Many native mobile apps are built the same way websites were built in the 1990s: a patchwork grid of sliced images butted up and layered over one another. Since a native app can load all of its assets on your device via the initial download, it can get away with using a lot of rasterized graphics. A web app will try to minimize the number of images it uses, however, since they're downloaded upon the first visits to any of the pages. To minimize the load, and generally provide site flexibility, many assets are built on-the-fly using CSS.
Modern CSS can produce gradients, drop shadows, inner shadows, rounded corners, and all manner of text effects. There are certainly more sophisticated effects you can only get by including an image, but many can be built on the browser end. A web developer will typically only pull the assets he absolutely needs from a PSD, and build the rest from scratch as best as he can. The more CSS is on a page, the more easily a visual can be changed, as it's mere keystrokes rather than the production and insertion of a new image asset.
CSS can be interpreted by devices in a variety of ways. It's natural for simple things like the darkness of shadows, the way a rounded corner renders, or the line-height of text to vary slightly from device to device. It's rare that a user will visit a site across several devices with distinct rendering engines, though, so as long as the site doesn't look broken, these little differences are entirely unnoticeable. Effort will be made by the developer to achieve parity, but in some instances the spirit of a design may be targeted in lieu of its exact specification.
The older a device is, however, the less likely it is that it'll support the entirety of the CSS spec. Accordingly, certain design patterns don't necessarily translate to a web app the same way they translate to a native one. One common issue is the lack of support for fixed-position background images, which when paired with poor support for HTML containers that scroll their internal content (a fixed-position background workaround), results in fixed-position backgrounds just not being possible in web apps. There are device and browser pairings that indeed produce the desired effect, but they regrettably don't comprise the vast majority of the devices on the marketplace.
Two important concepts in web development are those of progressive enhancement and graceful degradation. They imply a website that can look progressively nicer in newer web browsers, and one that degrades in older web browsers without ever feeling broken, ugly, or non-functional. While developing a native mobile app, the design is typically always the design, and will appear the same across devices. A web app, however, will often vary from device to device, depending upon the abilities of that device's web rendering engine. Accordingly, a design heavy in CSS gradients, shadows, and rounded corners may end up looking much flatter and pointier on, say, an ancient Android (or Windows Mobile) device. Sometimes only visual niceties will need to degrade, but other times the site may actually become less functional, such as pinned headers or footers no longer pinning correctly. These things will need to be understood when the design is being built, so that when certain items need to degrade on older devices, they degrade in a fashion that does not negatively impact the overall experience.
When building a "hybrid" app, which combines web code and native containers, you can get around some of these issues. For example, a native shell can have a fixed-position background image, while a web view can layer on top of it, producing the desired effect. The native shell can also handle all page transitions and layer in some native effects, producing a much smoother and more "native" feeling experience, while the actual components of the page are still web views. There are varying degrees of hybrid integration, where the more basic options merely load a website from a live server in a native shell, and more complicated ones integrate web code directly, and serve it up in the initial download package from an app store. Which approach is more appropriate depends ultimately upon the kind of product being produced.
Whether or not a developer can parse a PSD and pull out assets will vary from person to person. In most cases the developer can grab what they need, but there are some instances where it becomes much more difficult, depending upon how the PSD was built.
Sometimes an image, usually an icon for a button or something similar, will have various background detritus around its edges that gets hidden via layer blending. This makes it nigh-on impossible for a developer to get the image with a proper transparent background. Layer blending to remove backgrounds is fine for elements that will be locked to their backgrounds when they're sliced, but if the developer wants only the icon so he can build the background via CSS, make sure that the icon is clean and accessible for slicing by itself.
There are also cases where a PSD has a semi-transparent element, maybe a gradient, that the developer will want to reproduce via CSS. It can be difficult to sample the correct colors, or figure out the level of transparency, if the layer has been rasterized. If the effects are reversible, there's no problem. If not, though, it would be helpful to provide a reference for which colors were there before they were made transparent, and what the opacity level is set at. Better yet: don't rasterize, so that the developer can reverse-engineer an element to discover its source components.
Working with fonts
The latest CSS specifications support the inclusion of actual font files, rather than just relying on what a user already has installed on their machine. If you have a font file in the right format, it can be bundled with all of your web files and will load in the website like any other font. This gives a ton more flexibility in design, where one used to have to use images for any non-standard fonts.
That said, many fonts simply were not made for the web, or aren't old enough that the web was built around them. A great example is Helvetica Neue, which is exceedingly common in modern designs built on Apple computers. It's a font that isn't present on Windows machines or Android devices, so it needs to be included via CSS in order to function. It wasn't designed for web use, however, which means if you actually purchase the font and get it included, it may render very differently on non-Apple devices. Line-heights are the main culprit here, where trying to use a non-web-font across a variety of devices and operating systems will result in very different baselines, rendering the font largely useless in tight situations like navigations or buttons. Helvetica/Arial = good. Helvetica Neue = bad. If a font like that is only used in a loose callout location, though, where the exact line heights aren't as important, it might still be okay to work with.
When choosing the base font used for the majority of elements on a page, web-safe fonts are highly recommended. There are a set of web-safe font groups that are present on pretty much any machine, and these should form the foundation of a site. If a non-standard look is desired, though, seek out fonts that were actually designed for use on the web. Adobe makes a ton (like Source Sans Pro), but you can also get a huge amount of free fonts via services like Google Web Fonts. When putting together a design from scratch, try to choose your fonts from a service like this (Typekit is another popular option), or generally stick to those fonts that will definitely work well on the web. CSS fonts don't work in some older browsers, though, so a fallback font style should be chosen in those cases.
Websites are naturally fluid. Consider that your assets may need to stretch or smoothly elongate for different screen sizes or devices. Define rules for whether something should get bigger, get wider, move over, or just stay the same should the screen get larger or smaller.
Wireframes and information schematics are useful for communicating how a responsive design should perform, but they're also useful for conveying how the user should be able to interact with the app, and this informs how the developer will build it. Annotated wireframes should accompany all but the most bare-bones designs, and highlight how each part of the design should move and react to input.
It can be helpful to have assets provided to the developer at both LDPI and HDPI resolutions, rather than the developer sizing down HDPI assets when he needs LDPI ones. There are instances where in the process of resizing, an un-rasterized image will resize its source components, but not effects (like shadows/strokes), so the lower res asset will actually end up half small and half big. But when the assets are rasterized together and then resized, the quality of some elements can suffer. The more of this that can be addressed during the design phase, the better. There's no need to actually deliver the assets pre-sliced, but H/LDPI source documents where the designer has ensured that the assets have resized correctly would be ideal.
It's often helpful to just have a chat with the developer to hash out exactly how the assets should be produced, since the project may allow for certain elements to be built entirely with CSS.
Sometimes you'll work on a traditional desktop web project, and in that case most of these rules still apply. Even a site designed for a larger and mouse-driven screen will be regularly accessed via mobile devices, and should accommodate those devices with a responsive design and touch-friendly elements. This includes not relying too heavily on mouse-exclusive interaction paradigms like mouseovers.