Eu adorei ASIHTTPRequest e fiquei triste em vê-lo ir embora. No entanto, o desenvolvedor do ASI estava certo, ASIHTTPRequest se tornou tão grande e inchado que nem mesmo ele poderia dedicar tempo para torná-lo compatível com os recursos mais novos do iOS e outras estruturas. Eu mudei e agora uso AFNetworking.
Dito isso, devo dizer que AFNetworking é muito mais instável do que ASIHTTP, e para as coisas para as quais eu o uso, ele precisa de refinamento.
Freqüentemente, preciso fazer solicitações HTTP para 100 fontes HTTP antes de exibir meus resultados na tela e coloquei AFHTTPNetworkOperation em uma fila de operação. Antes de todos os resultados serem baixados, quero poder cancelar todas as operações dentro da fila de operações e, em seguida, dispensar o controlador de visualização que contém os resultados.
Isso nem sempre funciona.
Eu recebo travamentos em momentos aleatórios com AFNetworking, enquanto com ASIHTTPRequest, essas operações estavam funcionando perfeitamente. Eu gostaria de poder dizer qual parte específica do AFNetworking está travando, já que continua travando em pontos diferentes (no entanto, na maioria das vezes o depurador aponta para o NSRunLoop que cria um objeto NSURLConnection). Portanto, AFNetworking precisa amadurecer para ser considerado tão completo quanto ASIHTTPRequest era.
Além disso, ASIHTTPRequests oferece suporte à autenticação de cliente, que falta no AFNetworking no momento. A única maneira de implementá-lo é subclassificar AFHTTPRequestOperation e substituir os métodos de autenticação de NSURLConnection. No entanto, se você começar a se envolver com NSURLConnection, notará que colocar NSURLConnection dentro de um wrapper NSOperation e escrever blocos de conclusão não é tão difícil quanto parece e você começará a pensar no que o impede de despejar bibliotecas de terceiros.
ASI usa uma abordagem totalmente diferente, uma vez que usa CFNetworking (estruturas básicas de nível inferior baseadas em C) para fazer download e upload de arquivos possível, ignorando NSURLConnection completamente e tocando os conceitos que muitos de nós, desenvolvedores de OS X e iOS, temos muito medo de fazer. Por causa disso, você obtém um melhor upload e download de arquivos, até mesmo caches de páginas da web.
Qual eu prefiro? É difícil dizer. Se AFNetworking amadurecer o suficiente, vou gostar mais do que ASI. Até então, não posso deixar de admirar o ASI, e a maneira como ele se tornou um dos frameworks mais usados de todos os tempos para OS X e iOS.
EDIT:
Acho que é hora de atualizar essa resposta, pois as coisas mudaram um pouco depois desse post.
Esta postagem foi escrita há algum tempo e a AFNetworking amadureceu o suficiente. 1-2 meses atrás, o AF postou uma pequena atualização para operações POST que foi minha última reclamação sobre o framework (uma pequena falha de finalização de linha foi a razão pela qual os uploads echonest falharam com AF, mas foram concluídos sem problemas com ASI). A autenticação não é um problema com AFnetworking, pois para métodos de autenticação complexos você pode criar uma subclasse da operação e fazer suas próprias chamadas e AFHTTPClient torna a autenticação básica um pedaço de bolo. Ao criar uma subclasse de AFHTTPClient, você pode tornar um consumidor de serviço inteiro em pouco tempo.
Sem mencionar as adições UIImage absolutamente necessárias que a AFNetworking oferece. Com blocos e blocos de conclusão personalizados e algum algoritmo inteligente, você pode fazer visualizações de tabela com download de imagens assíncronas e preenchimento de células com bastante facilidade, enquanto em ASI você tinha que fazer filas de operação para limitação de largura de banda e se preocupar em cancelar e retomar a fila de operação de acordo com visibilidade da visualização da mesa e coisas assim. O tempo de desenvolvimento de tais operações foi reduzido pela metade.
Eu também adoro os blocos de sucesso e fracasso. ASI tem apenas um bloco de conclusão (que é realmente o bloco de conclusão de NSOperation). Você tinha que verificar se havia um erro na conclusão e agir de acordo. Para serviços da Web complexos, você pode se perder em todos os "ses" e "outros"; Na AFNetworking, as coisas são muito mais simples e intuitivas.
O ASI era ótimo para a época, mas com o AF você pode mudar completamente a maneira como lida com os serviços da web de uma maneira boa e tornar os aplicativos escaláveis com mais facilidade. Eu realmente acredito que não há mais razão para continuar com o ASI, a menos que você queira usar o iOS 3 e versões anteriores.
ASIFallbackToCacheIfLoadFailsCachePolicy
é muito bom. E acho que o AFNetworking não tem suporte para cache persistente. Isso é proibido para mim.